How to log in with slf4j from inside a jboss module?

Asked

Viewed 155 times

2

How can I log into the console / server.log from within a jboss module?

Let’s say I have a class:

public class MyClass {

    private static final Logger logger = LoggerFactory.getLogger(MyClass.class);

    private boolean done = false;

    public void doSomething() {
        logger.info("Look ma, I'm logging!");
        done = true;
    }

    public boolean isDone() {
        return done;
    }
}

If I want to log something from inside a deployed artifact (e. g., MyWebProject.war), all I have to do is:

  1. Compile against slf4j-api

    <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.7</version>
    <scope>provided</scope>
</dependency>

  2. Deploy

    ./jboss-cli.sh -c "deploy  MyWebProject.war"

  3. And just like that

    2015-10-19 11:04:02,445 INFO  [com.myCompany.MyClass] (default task-13) Look ma, I'm logging!

But I can’t in any way get the same effect from inside a jboss module.

Example: If MyWebProject.war uses MyModule.jar, and MyModule.jar is deployed as a jboss module:

${jbossHome}/modules/com/mycompany/mymodule/main
                                            |____ MyModule.jar
                                            |____ module.xml

Module.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="com.mycompany.mymodule">
  <resources>
    <resource-root path="MyModule.jar" />
  </resources>
  <dependencies>
    <module name="org.slf4j" />
  </dependencies>
</module>

If I move MyClass for MyModule.jar and use it on MyWebProject.war I can see the side effects (e. g., isDone() == true) but nothing is written for the server.log.

What am I forgetting? I need some other dependency besides slf4j?

Crosspost: Original question - Soen - How to log with slf4j from Within a jboss module?

java jboss wildfly slf4j jboss-modules

  • From the start I would guess that the log level is different. To make sure that I would change the info for error and repeat the test with the module.

  • Second thought: would it not be necessary to add as a module dependency a log implementation, such as the log4? This answer from OS lists some modules to be deleted so that the application uses the log system itself, so you may need to include them to use the Jboss log system.

  • A third alternative would be to start Jboss in debug mode and investigate what happens within the log routine. Does not solve the problem but can give a clue of what is missing.

  • Hello @utluiz, thank you for your prompt attention (as always). The standard logging level is for INFO on the server. Even so I tried to go up to ERROR (and, on the other side, set the logging levels to TRACE), nothing worked. I also think I’m needing a few more modules there, I just can’t figure out which ones... I’ll try the remote debugging.

  • To try to simulate here: which version of Jboss/Wildfly is using?

  • Hello Bruno: Wildfly 9.0.1 final

Show 1 more comment

1 answer

2


For future reference, my problem had nothing to do with logging. The above recipe works as expected. In fact, I suffered due to a false information: mine module.xml original was never really used. I was carrying an old class with the same name in another module. This old version of the class did not have logging and shouldn’t be there to begin with.

Anyway, I think the root cause of my problem (besides lack of attention) was a small bug in jboss-cli.

I was doing deploy of mymodule with the following command:

module add --name=com.mycompany.mymodule \
            --resources=MyModule.jar \
            --dependencies=org.slf4j \
            --main-class=com.mycompany.mymodule.Main

This command was generating a module.xml like this:

<?xml version="1.0" ?>

<module xmlns="urn:jboss:module:1.1" name="com.mycompany.mymodule">

    <main-class value="com.mycompany.mymodule.Main"/>

    <resources>
        <resource-root path="MyModule.jar"/>
    </resources>

    <dependencies>
        <module name="org.slf4j"/>
    </dependencies>
</module>

When I finally managed to get my web project to try to load the mymodule he failed with a stack trace like this:

18:45:59,999 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.module.service."deployment.MyWebProject.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.MyWebProject.war".main: WFLYSRV0179: Failed to load module: deployment.MyWebProject.war.war:main
    at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.modules.ModuleLoadException: Error loading module from C:\opt\server\wildfly-9.0.1.Final\modules\com\mycompany\mymodule\main\module.xml
    at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:150)
    at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:127)
    at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:150)
    at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:144)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144)
    at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:452)
    at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:355)
    at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:302)
    at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:313)
    at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:326)
    at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149)
    at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:234)
    at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:74)
    ... 5 more
Caused by: org.jboss.modules.xml.XmlPullParserException: Unexpected content of type 'element start' named 'main-class', text is: '<main-class value="com.mycompany.mymodule.Main"/>' (position: START_TAG seen ...n-class value="com.mycompany.mymodule.Main"/>... @5:54) 
    at org.jboss.modules.ModuleXmlParser.unexpectedContent(ModuleXmlParser.java:179)
    at org.jboss.modules.ModuleXmlParser.parseMainClass(ModuleXmlParser.java:620)
    at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:445)
    at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:261)
    at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:148)
    ... 18 more

Taking a look at the module-1_1.xsd I discovered that the element main-class was expecting an attribute name rather than an attribute value. So I modified the module.xml manually to:

<main-class name="com.mycompany.mymodule.Main"/>

After restarting the Wildfly and redeployar my web project everything worked as expected.

  • 1

    This is one of those moments of happiness in discovering a "silly" mistake after desperation to exhaust all possibilities and find that will have to change all architecture, vendor or technology not to get crazy. :)

Browser other questions tagged java jboss wildfly slf4j jboss-modules

You are not signed in. Login or sign up in order to post.