[infinispan-issues] [JBoss JIRA] (ISPN-8634) Wildfly 11 fails to start with Infinispan 9.x modules installed
Scott Van Wart (JIRA)
issues at jboss.org
Thu Dec 14 17:08:00 EST 2017
[ https://issues.jboss.org/browse/ISPN-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505678#comment-13505678 ]
Scott Van Wart edited comment on ISPN-8634 at 12/14/17 5:07 PM:
----------------------------------------------------------------
I also reported: https://issues.jboss.org/browse/ISPN-8633.
It looks like Wildfly 11 doesn't include a module named "org.jboss.sasl". Wildfly 10 did: wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/sasl.
If you look at the stack trace (second problem) in ISPN-8633, the exception thrown is java.lang.IllegalStateException
at org.jboss.as.controller.ParallelBootOperationContext.getManagementModel(ParallelBootOperationContext.java:133)
ParallelBootOperationContext.getManagementModel() has just a single line in it that throws this exception so it looks like an unintended use of the configuration model during startup (i.e. calling reloadRequired()).
Starting this configuration works just fine as long as no cache configurations are defined. It also seems to work all right (at first) if you wait for Wildfly 11 to boot, and then use the CLI to add a cache container (e.g. /subsystem=infinispan/cache-container=my-cache-container:add).
I'm not sure how the client JAR relates to my initial forum post but it looks like a separate issue from ISPN-8633.
was (Author: silvaran):
I also reported: https://issues.jboss.org/browse/ISPN-8633.
It looks like Wildfly 11 doesn't include a module named "org.jboss.sasl". Wildfly 10 did: wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/sasl.
If you look at the stack trace (second problem) in ISPN-8633, the exception thrown is java.lang.IllegalStateException
at org.jboss.as.controller.ParallelBootOperationContext.getManagementModel(ParallelBootOperationContext.java:133)
ParallelBootOperationContext.getManagementModel() has a single line in it that throws this exception so it looks like an unintended use of the configuration model during startup (i.e. calling reloadRequired()).
Starting this configuration works just fine as long as no cache configurations are defined. It also seems to work all right (at first) if you wait for Wildfly 11 to boot, and then use the CLI to add a cache container (e.g. /subsystem=infinispan/cache-container=my-cache-container:add).
I'm not sure how the client JAR relates to my initial forum post but it looks like a separate issue from ISPN-8633.
> 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
>
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
More information about the infinispan-issues
mailing list