Wildfly java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoader when using custom logging formatter

Question

I am using the default jboss-logging (LogManager) in Wildfly 10 and am attempting to create my own logging formatter.

I am configuring it like this in the standalone.xml:

    <subsystem xmlns="urn:jboss:domain:logging:3.0">
        <use-deployment-logging-config value="false"/>
        <console-handler name="CONSOLE">
            <level name="INFO"/>
            <formatter>
                <named-formatter name="JSON_PATTERN"/>
            </formatter>
        </console-handler>
        <formatter name="JSON_PATTERN">
            <custom-formatter
                    class="com.mycompany.JsonLogFormatter"
                    module="com.mycompany.logging"/>
        </formatter>
    </subsystem>

I created a jboss module like this:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.3" name="com.mycompany.logging">
    <resources>
        <resource-root path="log-utils-1.0.0.jar" />
    </resources>
    <dependencies>
        <module name="javax.json.api"/>
        <module name="org.jboss.logmanager" />
        <module name="org.jboss.logging" />
        <module name="org.jboss.modules"/>
    </dependencies>
</module>

where the log-utils-1.0.0.jar contains my JsonLogFormatter class and is located in the same directory as the module.xml (located in $JBOSS_HOME/modules/com/mycompany/logging/main)

When firing up the wildfly container, it fails to start and I am seeing this exception:

java.lang.IllegalArgumentException: Failed to load module "com.mycompany.logging" for formatter "JSON_PATTERN"
    at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:64) [jboss-logmanager-2.0.4.Final.jar:2.0.4.Final]
    at org.jboss.logmanager.config.FormatterConfigurationImpl.<init>(FormatterConfigurationImpl.java:30) [jboss-logmanager-2.0.4.Final.jar:2.0.4.Final]
    at org.jboss.logmanager.config.LogContextConfigurationImpl.addFormatterConfiguration(LogContextConfigurationImpl.java:171) [jboss-logmanager-2.0.4.Final.jar:2.0.4.Final]
    at org.jboss.as.logging.logmanager.ConfigurationPersistence.addFormatterConfiguration(ConfigurationPersistence.java:218)
    at org.jboss.as.logging.CustomFormatterResourceDefinition$2.performRuntime(CustomFormatterResourceDefinition.java:117)
    at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:204)
    at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:493) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:387) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:349) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.server.ServerService.boot(ServerService.java:397) [wildfly-server-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.server.ServerService.boot(ServerService.java:366) [wildfly-server-2.2.0.Final.jar:2.2.0.Final]
    at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.2.0.Final.jar:2.2.0.Final]
    at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151]
 Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoader
    at org.jboss.logmanager.config.AbstractPropertyConfiguration$ModuleFinder.getClassLoader(AbstractPropertyConfiguration.java:463) [jboss-logmanager-2.0.4.Final.jar:2.0.4.Final]
    at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:62) [jboss-logmanager-2.0.4.Final.jar:2.0.4.Final]
    ... 16 more

This all looks correct to me. You shouldn't even need a module dependency on `org.jboss.logging` or `org.jboss.modules` in your module. — James R. Perkins, Mar 19 '18 at 20:07
Looking at the actual stack trace, it looks as if WildFly's "org.jboss.logmanager" module is missing its "org.jboss.modules" dependency. I'm not sure why this would occur unless it were modified or overlaid somehow. — David M. Lloyd, Mar 20 '18 at 22:37
@DavidM.Lloyd I double checked the logmanager module.xml and it does specify the dependency on org.jboss.modules. Thanks for the input. — Jason White, Mar 22 '18 at 15:09
The only reason I could imagine that you would have to add the jboss modules JAR to the boot classpath would be that you also added the log manager JAR there. Overall not recommended. — David M. Lloyd, Mar 22 '18 at 15:18
@DavidM.Lloyd yes, I have the log manager jar on the boot classpath. If I remove it, I get ClassNotFoundExceptions. I see a lot of posts recommending this approach. What would be the recommended way if not doing this? — Jason White, Mar 26 '18 at 23:51
@DavidM.Lloyd I currently have these JAVA_OPTS set: `-Djava.util.logging.manager=org.jboss.logmanager.LogManager -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Xbootclasspath/p:$JBOSS_HOME/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.4.Final.jar -Xbootclasspath/p:$JBOSS_HOME/jboss-modules.jar` — Jason White, Mar 27 '18 at 00:06
@JasonWhite it depends on why you have the log manager on the boot classpath to begin with. Usually you should not do that; you didn’t mention it in the original question so it’s not clear why it is necessary. — David M. Lloyd, Mar 27 '18 at 01:23
@DavidM.Lloyd it all follows from the fact that I have the logging manager set to be the jboss LogManager: `-Djava.util.logging.manager=org.jboss.logmanager.LogManager` When I set this, it forces me to have the logmanager jar in the boot classpath. If I don't set this initial logging manager setting, I get an exception. — Jason White, Mar 27 '18 at 15:56
You should not need to do that, unless you are trying to use an agent which does logging or something like that. Is that what you're doing? — David M. Lloyd, Mar 27 '18 at 16:22
@DavidM.Lloyd yes, I have an agent (prometheus jmx exporter) set up like this `-javaagent:/opt/prometheus/jmx_prometheus_java_agent.jar=31500:/opt/prometheus/prometheus.yaml` When I take this agent out of play, it works fine w/o having to set all of the log manager stuff up. I guess that leads to another question of whether there is a better way of doing this with the constraint of having this agent in place. Thanks! — Jason White, Mar 27 '18 at 16:41
Ah I see. Yeah agents are a tough problem that we don’t have a better solution for - yet. I hope to have one soon though, for Java 9+ at least. — David M. Lloyd, Mar 27 '18 at 18:00

Jason White · Accepted Answer · 2018-03-27T16:54:10.457

I was able to get a clean start up, w/o the exception, when I added the following parameter to the JAVA_OPTS environment:

JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:$JBOSS_HOME/jboss-modules.jar"

I got the idea from this page: https://inspectit-performance.atlassian.net/wiki/spaces/DOC17/pages/54657166/JBoss+6.x

Updated Information:

My full set of JAVA_OPTS are these:

-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m 
-Djava.net.preferIPv4Stack=true 
-Djava.awt.headless=true 
-Djboss.https.port=8443 
-Djboss.http.port=8080 
-Djboss.bind.address=0.0.0.0 
-Djboss.server.log.dir=/home/app/logs 
-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n 
-DconfigurationLocationStrategy=filesystem 
-Djava.util.logging.manager=org.jboss.logmanager.LogManager 
-Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager 
-Xbootclasspath/p:/home/app/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.4.Final.jar 
-Xbootclasspath/p:/home/app/wildfly/jboss-modules.jar 
-javaagent:/opt/prometheus/jmx_prometheus_java_agent.jar=31500:/opt/prometheus/prometheus.yaml

It appears the need for doing all of the logmanager properties arose from the fact that I have deployed a prometheus agent with my container.

If I don't deploy the prometheus agent, I don't need to add any of the logmanager parameters to the JAVA_OPTS. Unfortunately, not deploying this agent is not an option.

While it may work for now it does no look like the correct solution. — Philippe Marschall, Mar 19 '18 at 15:48
yeah, it feels like a hack, so I'm all ears for a better solution here. — Jason White, Mar 19 '18 at 23:04
I looks correct to me and should work. We have something similar and it works for us. We have no dependency on "org.jboss.logging" and "org.jboss.modules" but instead add a dependency to ""javax.xml.stream.api". — Philippe Marschall, Mar 20 '18 at 10:44
@PhilippeMarschall thanks, I took out the dependency on org.jboss.logging and org.jboss.modules in the module.xml, although I still need to add the -Xbootclasspath option I mentioned above to make it work. — Jason White, Mar 20 '18 at 21:30
For me this works only if JAVA_OPTS="$JAVA_OPTS -Dmodule.path=$JBOSS_HOME/modules" is added also — Marcus Linke, Oct 18 '18 at 12:10

Wildfly java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoader when using custom logging formatter

1 Answers1