11:08 p.m.
[
https://issues.jboss.org/browse/ISPN-8634?page=com.atlassian.jira.plugin....
]
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)
2598
days inactive
2598
days old
infinispan-issues@lists.jboss.org
0 comments
1 participants
participants (1)
-
Scott Van Wart (JIRA)