Wildfly 11 fails to start with Infinispan 9.x modules installed --------------------------------------------------------------- Key: ISPN-8634 URL: https://issues.jboss.org/browse/ISPN-8634 Project: Infinispan Issue Type: Bug Components: Integration Affects Versions: 9.2.0.Beta1, 9.1.3.Final Reporter: Alan Field Assignee: Ryan Emerson A user on the forums reported that he got the following errors starting up Wildfly 11 with the Infinispan 9.1 modules installed and the extensions added to the {{standalone.xml}} file: {noformat} 14:25:14,340 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) at org.jboss.as.server.ServerService.boot(ServerService.java:387) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370) at java.lang.Thread.run(Thread.java:748) Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.infinispan.server.endpoint:ispn-9.2 at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154) at org.jboss.as.server.parsing.StandaloneXml$DefaultExtensionHandler.parseExtensions(StandaloneXml.java:131) at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:219) at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:142) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122) at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126) ... 3 more Caused by: java.util.concurrent.ExecutionException: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146) ... 11 more Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:195) at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68) at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126) at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: org.jboss.modules.ModuleNotFoundException: org.jboss.sasl at org.jboss.modules.Module.addPaths(Module.java:1217) at org.jboss.modules.Module.link(Module.java:1573) at org.jboss.modules.Module.relinkIfNecessary(Module.java:1601) at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:287) at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:271) at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:177) ... 8 more {noformat} This also happens with the 9.2.0.Beta1 modules. Wildfly 11 includes a {{bin/client/README-EJB-JMS.txt}} file that states: {noformat} jboss-client.jar is a combined client jar for WildFly, for use in non-maven environments. This jar should be used with standalone clients only, not with deployments are that deployed to a WildFly instance. This jar contains the classes required for remote JMS and EJB usage, and consists of the following shaded artifacts: org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec com.google.guava:guava commons-beanutils:commons-beanutils commons-collections:commons-collections io.netty:netty-all org.apache.activemq:artemis-commons org.apache.activemq:artemis-core-client org.apache.activemq:artemis-hqclient-protocol org.apache.activemq:artemis-jms-client org.jboss:jboss-ejb-client org.jboss:jboss-remote-naming org.jboss.logging:jboss-logging org.jboss.marshalling:jboss-marshalling org.jboss.marshalling:jboss-marshalling-river org.jboss.remoting:jboss-remoting org.jboss.remotingjmx:remoting-jmx org.jboss.sasl:jboss-sasl org.jboss.xnio:xnio-api org.jboss.xnio:xnio-nio org.jgroups:jgroups org.slf4j:slf4j-api org.slf4j:jcl-over-slf4j Maven users should not use this jar, but should use the following BOM dependencies instead <dependencies> <dependency> <groupId>org.wildfly</groupId> <artifactId>wildfly-ejb-client-bom</artifactId> <type>pom</type> </dependency> <dependency> <groupId>org.wildfly</groupId> <artifactId>wildfly-jms-client-bom</artifactId> <type>pom</type> </dependency> </dependencies> This is because using maven with a shaded jar has a very high chance of causing class version conflicts, which is why we do not publish this jar to the maven repository. {noformat} The modules will need to modified to deal with this.