Develop Reference

chronicle with corretto jdk17 java.lang.NoSuchMethodError: 'sun.misc.Cleaner sun.nio.ch.DirectBuffer.cleaner()'

Trying to follow the guide on the chronicle blog. Have upgraded jars and added the following jvm options :
JDK17_VM_ARGS="-Dio.netty.tryReflectionSetAccessible=true
--add-exports=java.base/jdk.internal.ref=ALL-UNNAMED
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED
--add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-opens=jdk.compiler/com.sun.tools.javac=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.lang.reflect=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/sun.nio.ch=ALL-UNNAMED "
DEFAULT_VM_ARGS="-XX:+UseParallelGC -Xms16g -Xmx16g -XX:NewRatio=3 -XX:MaxGCPauseMillis=500"
But still get the following exception
ERROR: Uncaught Exception: chronicle-source-1
java.lang.NoSuchMethodError: 'sun.misc.Cleaner
sun.nio.ch.DirectBuffer.cleaner()' at
net.openhft.lang.io.VanillaMappedBytes.cleanup(VanillaMappedBytes.java:95)
~[lang-6.8.2.jar:?] at
net.openhft.lang.io.AbstractBytes.release(AbstractBytes.java:646)
~[lang-6.8.2.jar:?] at
net.openhft.lang.io.VanillaMappedBytes.release(VanillaMappedBytes.java:86)
~[lang-6.8.2.jar:?] at
net.openhft.lang.io.VanillaMappedBlocks.acquire0(VanillaMappedBlocks.java:63)
~[lang-6.8.2.jar:?] at
net.openhft.lang.io.VanillaMappedBlocks.acquire(VanillaMappedBlocks.java:57)
~[lang-6.8.2.jar:?] at
net.openhft.chronicle.IndexedChronicle$AbstractIndexedExcerpt.setDataBuffer(IndexedChronicle.java:515)
~[chronicle-3.6.4.jar:?] at
net.openhft.chronicle.IndexedChronicle$AbstractIndexedExcerpt.indexForRead(IndexedChronicle.java:440)
~[chronicle-3.6.4.jar:?] at
net.openhft.chronicle.IndexedChronicle$IndexedExcerptTailer.index(IndexedChronicle.java:964)
~[chronicle-3.6.4.jar:?] at
net.openhft.chronicle.tcp.SourceTcp$IndexedSessionHandler.write(SourceTcp.java:551)
~[chronicle-3.6.4.jar:?] at
net.openhft.chronicle.tcp.SourceTcp$SessionHandler.onWrite(SourceTcp.java:365)
~[chronicle-3.6.4.jar:?] at
net.openhft.chronicle.tcp.SourceTcp$SessionHandler.onSelectionKey(SourceTcp.java:327)
~[chronicle-3.6.4.jar:?] at
net.openhft.chronicle.tcp.SourceTcp$SessionHandler.vanillaNioLoop(SourceTcp.java:245)
~[chronicle-3.6.4.jar:?] at
net.openhft.chronicle.tcp.SourceTcp$SessionHandler.run(SourceTcp.java:195)
~[chronicle-3.6.4.jar:?] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
~[?:?] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
~[?:?] at java.lang.Thread.run(Thread.java:833) [?:?]
This is using amazon correto

Chronicle 3.6.4 was released in Jan 2017 and only supported on Java 7 and 8. (It was released before Java 11)
If you need this version of Chronicle, I suggest only using Java 8.
If you need a newer JVM, I suggest using Chronicle Queue 5.22 or later.

Using Java 8 with Embedded jetty Error

I work with Jetty. But when I trying to use in my code Java 8 futures I see error when open first page:
23-05-2017 16:34:27:896 WARN ContextHandler$Context log unavailable
java.lang.ArrayIndexOutOfBoundsException: 27745
at org.objectweb.asm.ClassReader.readClass(ClassReader.java:2015)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:469)
at org.objectweb.asm.ClassReader.accept(ClassReader.java:425)
at org.glassfish.jersey.server.internal.scanning.AnnotationAcceptingListener.process(AnnotationAcceptingListener.java:167)
at org.glassfish.jersey.server.ResourceConfig.scanClasses(ResourceConfig.java:850)
at org.glassfish.jersey.server.ResourceConfig._getClasses(ResourceConfig.java:808)
at org.glassfish.jersey.server.ResourceConfig.getClasses(ResourceConfig.java:723)
at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1120)
at org.glassfish.jersey.server.ResourceConfig$RuntimeConfig.<init>(ResourceConfig.java:1093)
at org.glassfish.jersey.server.ResourceConfig.createRuntimeConfig(ResourceConfig.java:1089)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:275)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:262)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:349)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:637)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:498)
at org.eclipse.jetty.servlet.ServletHolder.ensureInstance(ServletHolder.java:785)
at org.eclipse.jetty.servlet.ServletHolder.prepare(ServletHolder.java:770)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:538)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1239)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:481)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1561)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1141)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:118)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:564)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
at java.lang.Thread.run(Thread.java:745)
23-05-2017 16:34:27:898 WARN HttpChannel handleException /gains/login/checksession
javax.servlet.ServletException: javax.servlet.ServletException: org.glassfish.jersey.servlet.ServletContainer-69d45cca#3758310d==org.glassfish.jersey.servlet.ServletContainer,jsp=null,order=-1,inst=false
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:138)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:564)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.servlet.ServletException: org.glassfish.jersey.servlet.ServletContainer-69d45cca#3758310d==org.glassfish.jersey.servlet.ServletContainer,jsp=null,order=-1,inst=false
We thought we avoid that issue if we update Jetty libs but issue still reproduces.
We use Jetty 9.4.

I guess you are using the old version of asm.jar with newer compiled Java bytecode.
For Java 8 bytecode, use asm 5.0.1+
See Strange java.lang.ArrayIndexOutOfBoundsException thrown on jetty startup
Dont't forget to update cglib.jar to a proper version because it has the asm as a dependency

Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 118

I have upgraded from jdk1.6(32) to jdk1.8(64) and Netbeans from 6.* to 8.*.
Configured setup and successfully updated the project.jar files. Few of the external jars are taken as it is which are listed below:
file.reference.bcmail-jdk16-136.jar
file.reference.bcprov-jdk16-136.jar
file.reference.jcommon-1.0.10.jar
file.reference.jdepend.jar
file.reference.jfreechart-1.0.9.jar
file.reference.log4j-1.2.14.jar
file.reference.registry.jar
file.reference.swingx.jar
file.reference.jshrink.jar
Now, I am prepared app.exe from inno setup and deployed exe, I am getting following error pop-up message when I am try to run exe: "A JNI error has occurred, please check your installation and try again"
When try to run from command prompt I got following stacktrace:
C:\Users\100755224>java -jar C:\Dev_TSOFT\Sources\installer\tsoft\TSOFT.jar
===============================
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 118
Exception Details:
Location:
com/alstom/tsoft/Main.<init>([Ljava/lang/String;)V #56: ifeq
Reason:
Expected stackmap frame at this location.
Bytecode:
0x0000000: 2ab7 0002 2a11 7d91 b500 032a 1204 b500
0x0000010: 052a bb00 0659 2ab7 0007 b500 082a bb00
0x0000020: 0959 117d 9112 042a b400 08b7 000b b500
0x0000030: 0c2a b400 0cb6 000d 9900 3eb8 000e b800
0x0000040: 0fa7 0004 4d04 b800 112b be04 a000 142a
0x0000050: bb00 1259 2b03 32b7 0013 b500 01a7 000e
0x0000060: 2abb 0012 59b7 0014 b500 012a b400 01b6
0x0000070: 0015 04b6 0016 b1
Exception Handler Table:
bci [59, 65] => handler: 68
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
at java.lang.Class.privateGetMethodRecursive(Unknown Source)
at java.lang.Class.getMethod0(Unknown Source)
at java.lang.Class.getMethod(Unknown Source)
at sun.launcher.LauncherHelper.validateMainClass(Unknown Source)
at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
I have set the library and source JDK version to jdk8. Please suggest, its a work stopper for me since 4 days.
Thanks in advance

I came to know where the problem is,
inno setup is using old jre i.e 1.6, I need to update that jre.
Now the question is how to update inno setup jre files ?
Please let me know if any one is aware.
Thanks

Getting AbstractMethodError while creating a connection to Oracle9 database with Tomcat 8 server

I am getting the below error when I start the Tomcat 8 server.
I am using ojdbc14.jar and I have tried with ojdbc6.jar as well,but its not working.This is happening only with Tomcat 8. If I use Tomcat 7 then it is not throwing any exception. JRE version is 7
Caused by: java.lang.AbstractMethodError:
oracle.jdbc.driver.T4CConnection.isValid(I)Z at
org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.isValid(DelegatingConnection.java:917)
at
org.apache.tomcat.dbcp.dbcp2.PoolableConnection.validate(PoolableConnection.java:282)
at
org.apache.tomcat.dbcp.dbcp2.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:356)
at
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.validateConnectionFactory(BasicDataSource.java:2306) at
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:2289)
at
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:2038)
at
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1532)
at
org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:70)
at
org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProviderJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:242)
at
org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:117)
at
org.hibernate.service.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:75)
at
org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
at
org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
at
org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:78)
at
org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:2283)
at
org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2279)
at
org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1748)
at
org.hibernate.ejb.EntityManagerFactoryImpl.(EntityManagerFactoryImpl.java:94)
at
org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:920)
at
org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904)
at
org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:92)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:290)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1571)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1509)
... 21 more

Use ojdbc7.jar with Java 7, it should work.

Seam application fails to deploy on JBoss AS5

UPDATE: This problem goes away when I deploy as an exploded EAR i.e. by unzipping the EAR, WAR and JAR files into their constituent components. Weird.
I have a Seam application (using 2.2.1-Final) which I'm trying to deploy on a brand-new JBoss AS 5 instance. The application is built using Maven.
When I deploy the app on JBoss the EJB portion starts up without incident, as does the Persistence stuff, but on the deploy of the web portion I get a stream of errors, all to do with missing JARs, both in the WEB-INF/lib and in the lib directory of the EAR.
The jars referred to are the Seam ones (Seam, Seam UI, Seam Remoting etc) and they are physically present in the specified locations.
Has anyone come across this before? I'm fairly sure I'm doing something wrong but can't figure out what - all help gratefully accepted!
EDIT - stacktrace added. There are other errors of the same type pointing to other Seam JARs below this one:
2011-04-04 10:47:58,968 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) deploy, ctxPath=/DublinHelpers-war
2011-04-04 10:47:59,265 INFO [javax.enterprise.resource.webcontainer.jsf.config] (main) Initializing Mojarra (1.2_12-b01-FCS) for context '/DublinHelpers-war'
2011-04-04 10:48:00,390 INFO [javax.servlet.ServletContextListener] (main) Welcome to Seam 2.2.1.Final
2011-04-04 10:48:00,484 WARN [org.jboss.seam.deployment.URLScanner] (main) could not read entries
java.io.FileNotFoundException: C:\jboss-5.1.0.GA\server\default\deploy\DublinHelpers-ear-1.1.0-SNAPSHOT.ear\DublinHelpers-war.war\WEB-INF\lib\jboss-seam-2.2.1.Final.jar (The system cannot find the path specified)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:127)
at java.util.zip.ZipFile.<init>(ZipFile.java:144)
at org.jboss.seam.deployment.URLScanner.handleArchiveByFile(URLScanner.java:123)
at org.jboss.seam.deployment.URLScanner.handle(URLScanner.java:107)
at org.jboss.seam.deployment.URLScanner.scanResources(URLScanner.java:90)
at org.jboss.seam.deployment.StandardDeploymentStrategy.scan(StandardDeploymentStrategy.java:119)
at org.jboss.seam.init.Initialization.create(Initialization.java:130)
at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:36)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
at $Proxy38.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:662

I went back to this in recent days, and discovered the solution through a mixture of good googling and blind luck.
An EAR file containing Seam must only have 1 main Seam jar in it - the other jars (-excel etc) are fine, but there must only be 1 main jar. My deployment had one in the WEB-INF/lib too, brought in by dependencies through Maven. A little research through the Eclipse POM editor allowed me to determine what jar had the dependency, and exclude it in the POM. The result was a perfectly-deploying EAR file.

Silly answer, but just to be sure. Is your WEB-INF/lib spelling WEB-dash-INF-slash-lib, and not WEB-underscore-INF-slash-lib as written in the post?