[JBoss JIRA] (WFLY-12606) Unable to configure system-jmx module in standalone.xml
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12606?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-12606:
------------------------------------
Priority: Major (was: Blocker)
> Unable to configure system-jmx module in standalone.xml
> -------------------------------------------------------
>
> Key: WFLY-12606
> URL: https://issues.jboss.org/browse/WFLY-12606
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 17.0.1.Final
> Reporter: Shashank Singhal
> Assignee: Richard Opalka
> Priority: Major
> Attachments: standalone.xml
>
>
> I am trying to migrate a project from Jboss 4 to wildfly 17 which doesn't have much except JMS queue related stuff.
> I am getting following error:
> 11:46:53,671 WARN [org.jboss.modules.define] (MSC service thread 1-8) Failed to define class com.XXXXX.ifmbase.controller.IFMController in Module "deployment.ifmdxb-ear.ear.ifmbase-ejb.jar" from Service Module Loader:
> java.lang.NoClassDefFoundError: Failed to link XXXXXXXXXX (Module "deployment.ifmdxb-ear.ear.ifmbase-ejb.jar" from Service Module Loader): Failed to link XXXXXXXXXX (Module "deployment.ifmdxb-ear.ear.ifmbase-ejb.jar" from Service Module Loader): org/jboss/system/ServiceMBean
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1095)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1095)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:415)
> at org.jboss.as.sar@17.0.0.Final//org.jboss.as.service.ReflectionUtils.getClass(ReflectionUtils.java:139)
> at org.jboss.as.sar@17.0.0.Final//org.jboss.as.service.ReflectionUtils.getClassHierarchy(ReflectionUtils.java:148)
> at org.jboss.as.sar@17.0.0.Final//org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:119)
> at org.jboss.as.sar@17.0.0.Final//org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:109)
> at org.jboss.as.server@9.0.1.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> at org.jboss.msc@1.4.7.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1737)
> at org.jboss.msc@1.4.7.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1699)
> at org.jboss.msc@1.4.7.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1557)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:835)
> In effort to try fixing this, I was trying to add the system-jmx module in wildfly-17.0.1.Final\modules\system\layers\base\org\jboss\as folder and tried defining it in standalone.xml as follows under extensions:
> <extension module="org.jboss.as.system-jmx"/>
> That also didn't seem to work out and got error as:
> 10:03:09,457 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configurati
> on
> at org.jboss.as.controller@9.0.2.Final//org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
> at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.ServerService.boot(ServerService.java:385)
> at org.jboss.as.controller@9.0.2.Final//org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
> at java.base/java.lang.Thread.run(Thread.java:835)
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.jboss.as.system-jmx
> at org.jboss.as.controller@9.0.2.Final//org.jboss.as.controller.parsing.DeferredExtensionContext.load(DeferredExtensionContext.java:100)
> at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.parsing.StandaloneXml_10.readServerElement(StandaloneXml_10.java:237)
> at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.parsing.StandaloneXml_10.readElement(StandaloneXml_10.java:137)
> at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:126)
> at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:52)
> at org.jboss.staxmapper@1.3.0.Final//org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
> at org.jboss.staxmapper@1.3.0.Final//org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
> at org.jboss.as.controller@9.0.2.Final//org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12606) Unable to configure system-jmx module in standalone.xml
by Shashank Singhal (Jira)
Shashank Singhal created WFLY-12606:
---------------------------------------
Summary: Unable to configure system-jmx module in standalone.xml
Key: WFLY-12606
URL: https://issues.jboss.org/browse/WFLY-12606
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 17.0.1.Final
Reporter: Shashank Singhal
Assignee: Richard Opalka
Attachments: standalone.xml
I am trying to migrate a project from Jboss 4 to wildfly 17 which doesn't have much except JMS queue related stuff.
I am getting following error:
11:46:53,671 WARN [org.jboss.modules.define] (MSC service thread 1-8) Failed to define class com.XXXXX.ifmbase.controller.IFMController in Module "deployment.ifmdxb-ear.ear.ifmbase-ejb.jar" from Service Module Loader:
java.lang.NoClassDefFoundError: Failed to link XXXXXXXXXX (Module "deployment.ifmdxb-ear.ear.ifmbase-ejb.jar" from Service Module Loader): Failed to link XXXXXXXXXX (Module "deployment.ifmdxb-ear.ear.ifmbase-ejb.jar" from Service Module Loader): org/jboss/system/ServiceMBean
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1095)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
at org.jboss.modules.Module.loadModuleClass(Module.java:731)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1095)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
at org.jboss.modules.Module.loadModuleClass(Module.java:731)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:415)
at org.jboss.as.sar@17.0.0.Final//org.jboss.as.service.ReflectionUtils.getClass(ReflectionUtils.java:139)
at org.jboss.as.sar@17.0.0.Final//org.jboss.as.service.ReflectionUtils.getClassHierarchy(ReflectionUtils.java:148)
at org.jboss.as.sar@17.0.0.Final//org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:119)
at org.jboss.as.sar@17.0.0.Final//org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:109)
at org.jboss.as.server@9.0.1.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
at org.jboss.msc@1.4.7.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1737)
at org.jboss.msc@1.4.7.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1699)
at org.jboss.msc@1.4.7.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1557)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
at java.base/java.lang.Thread.run(Thread.java:835)
In effort to try fixing this, I was trying to add the system-jmx module in wildfly-17.0.1.Final\modules\system\layers\base\org\jboss\as folder and tried defining it in standalone.xml as follows under extensions:
<extension module="org.jboss.as.system-jmx"/>
That also didn't seem to work out and got error as:
10:03:09,457 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configurati
on
at org.jboss.as.controller@9.0.2.Final//org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.ServerService.boot(ServerService.java:385)
at org.jboss.as.controller@9.0.2.Final//org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:374)
at java.base/java.lang.Thread.run(Thread.java:835)
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.jboss.as.system-jmx
at org.jboss.as.controller@9.0.2.Final//org.jboss.as.controller.parsing.DeferredExtensionContext.load(DeferredExtensionContext.java:100)
at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.parsing.StandaloneXml_10.readServerElement(StandaloneXml_10.java:237)
at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.parsing.StandaloneXml_10.readElement(StandaloneXml_10.java:137)
at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:126)
at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:52)
at org.jboss.staxmapper@1.3.0.Final//org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
at org.jboss.staxmapper@1.3.0.Final//org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
at org.jboss.as.controller@9.0.2.Final//org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12605) Clean out cruft EJB content from the ear used for web SSO testing
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12605?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFLY-12605.
-------------------------------------
Resolution: Won't Do
Won't do. There seems to be some point to this EJB stuff that should perhaps be restored (but in such a way that the app is still useful in a non-EJB server; e.g. EJBServlet can have the EJB lookup uncommented by a NNFE is ignored.)
> Clean out cruft EJB content from the ear used for web SSO testing
> -----------------------------------------------------------------
>
> Key: WFLY-12605
> URL: https://issues.jboss.org/browse/WFLY-12605
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> The application deployed for web SSO testing is an ear that includes an EJB jar. The EJBs are not used in any tests; the servlets in the EAR do not reference them. (There's some code commented out in 2012 that indicates there was a plan to, but it's not been done in 7 years.)
> The web.xml sets up some JNDI mappings for the EJBs, but nothing uses those. The ear can actually deploy just fine in a server without any ejb subystem.
> Task is to clean this ejb stuff out so it's more obvious tests using this deployment are suitable for execution against a slimmed server that does not include ejb support.
> Low priority because such tests can actually pass fine without this cleanup; it's just a source of confusion when trying to understand what's going on if there's any problem with the test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12605) Clean out cruft EJB content from the ear used for web SSO testing
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12605:
---------------------------------------
Summary: Clean out cruft EJB content from the ear used for web SSO testing
Key: WFLY-12605
URL: https://issues.jboss.org/browse/WFLY-12605
Project: WildFly
Issue Type: Task
Components: Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The application deployed for web SSO testing is an ear that includes an EJB jar. The EJBs are not used in any tests; the servlets in the EAR do not reference them. (There's some code commented out in 2012 that indicates there was a plan to, but it's not been done in 7 years.)
The web.xml sets up some JNDI mappings for the EJBs, but nothing uses those. The ear can actually deploy just fine in a server without any ejb subystem.
Task is to clean this ejb stuff out so it's more obvious tests using this deployment are suitable for execution against a slimmed server that does not include ejb support.
Low priority because such tests can actually pass fine without this cleanup; it's just a source of confusion when trying to understand what's going on if there's any problem with the test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years