Wildfly + slf4j - why so hard?

[rustydee]

OK, I'll admit I'm fairly new to using this combination of tools and libraries, so I could be making a silly mistake, there could be an issue with any single component, or the combination may not work period.

What am I using?

Eclipse Luna with JBoss Tools

Wildfly 8.1

ws.rs.core.Application to create very simple RESTful web app

slf4j1.7.5

maven

I have a very simple REST endpoint that returns a text string and this works as expected when I deploy to Wildfly server running within Eclipse - i.e. my browser shows the expected text string.

BUT, I also have an slf4j log message in that method, and it doesn't send anything out to the log console. I've tried for a few hours this evening, to try and get this to work, but with no luck. Without (at this stage) getting into my posting lots of config files, etc, can anybody point me to an idiots guide that spells out how to get slf4j log messages out of my web app?

I tried adding slf4j to my pom file, included it as a manifest dependency in the war plugin, added jboss-deploymentment-structure files to META-INF (which doesn't feel correct) to exlude default logging modules, and set the 'add-logging-api-dependencies' to false in the wildfly cli gui. Nothing seems to show the faintest hope of working.

Have I completely missed the mark? Should this just be working, or do I need to apply some more 'magic'? Are the correct versions of the above critical?

Like I said, if anyone can point out an idiots guide that I could follow, rather that getting too involved in my particular configuration, then that would be useful at this stage.

[dibu]

Wildfly already contains a slf4j (v1.7.2) module (see WILDFLY_HOME/modules). If you use maven add the following dependency to your maven pom file.

<dependency>

     <groupId>org.slf4j</groupId>

     <artifactId>slf4j-api</artifactId>

     <version>1.7.2</version>

     <scope>provided</scope>

</dependency>

Now add a jboss-deployment-structure.xml to your project. Must be placed under the META-INF or the WEB-INF (web project) directory.

<?xml version="1.0" encoding="UTF-8"?>

<jboss-deployment-structure>

  <deployment>

    <dependencies>

      <!-- add your project dependencies here -->

      <module name="org.slf4j" />

    </dependencies>

  </deployment>

</jboss-deployment-structure>

Use the slf4j Logger like this.

Logger logger = LoggerFactory.getLogger(MyClass.class);

logger.info("method called");

This worked in my short test.

[rcd]

I have a project where some components use SLF4J and did not need jboss-deployment-structure.xml or a Manifest dependency. You should add the SLF4J API to your POM with provided scope, as Dirk noted, and also make sure that you do NOT have any implementations in your deployment. So no Logback, no redirect to Log4j, etc. WildFly will supply an implementation of SLF4J that bridges it into the JBoss Logging system. Finally, you might double check your logging configuration to make sure the log category and console handler have the right log levels set. With the default configuration, your log statement would have to be at INFO level or above.

[rustydee]

OK - thank you both.

I decided that my best option was to start again from scratch, using the JBoss tools - and this has taken me a few hours to sort out!

What I hadn't stated originally was that my 'simple' project was copied from somewhere else. That project had a lot of dependencies (despite there not being much code in it), and buried away inside an 'uber' jar (created with the maven shade plugin - I told you a lot of this was new to me!) were the slf4j classes.

So what appears to have stopped slf4j working was the duplicate inclusion of slf4j libraries in my deployment. Minus that, just referencing the slf4j API in my POM would otherwise appear to be enough to get the logging 'working'.

I say 'appears', but I haven't yet tried this out on the original project. But I'm confident that you've helped me isolate the problem. I'll have to see if I can get slf4j excluded from that 'uber' jar, as I think I'm still going to need it for my 'real' app.

[rcd]

Glad to be of help. You should be able to use jboss-deployment-structure.xml to filter out those unwanted shaded classes, if all else fails. Check out the example deployment structure at Class Loading in WildFly - WildFly 8 - Project Documentation Editor. Part of the example filters out classes from a library included in the deployment.

[rustydee]

I'm reading through that page now, and it look's like it could be a lot of trial-and-error pain coming my way, if I go down that route. But ... I guess it's probably the simplist (if I can get it to work) solution to my problem.

[rustydee]

So I've created a jboss-deployment-structure.xml file in my WEB-INF directory as follows:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <module name="deployment.jboss-forge-html5">
        <resources>
            <resource-root path="shared-1.1-SNAPSHOT.jar">
                <filter>
                    <exclude path="org/slf4j" />
                </filter>
            </resource-root>
        </resources>
    </module>
</jboss-deployment-structure>

But I'm getting an error in my logs that indicates I've 'guessed' something wrong:

11:47:47,917 WARN  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015959: Additional resource root /C:/tools/wildfly8.1/standalone/deployments/jboss-forge-html5.war/shared-1.1-SNAPSHOT.jar added via jboss-deployment-structure.xml does not exist

Is there something obvious that I've done wrong?

[rcd]

I'm guessing the resource-root is wrong. The warning says it's looking for jboss-forge-html5.war/shared-1.1-SNAPSHOT.jar, but if you include a library in Maven, it goes in the WAR's WEB-INF/lib. So you probably just need to change the resource-root path to "WEB-INF/lib/shared-1.1-SNAPSHOT.jar".

[rustydee]

Yes, it looks like you are correct. Although I still had some WARN messages in my Wildfly log output that led me to belive that it wasn't working, I did end up seeing SLF4J log messages in my console output. So thanks again.

For completeness sake, here is my final (and working) jboss-deployment-structure.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <module name="deployment.jboss-forge-html5">
        <resources>
            <resource-root path="WEB-INF/lib/shared-1.1-SNAPSHOT.jar">
                <filter>
                    <exclude path="org/slf4j" />
                </filter>
            </resource-root>
        </resources>
    </module>
</jboss-deployment-structure>

[ctomc]

R D wrote:

Yes, it looks like you are correct. Although I still had some WARN messages in my Wildfly log output that led me to belive that it wasn't working, I did end up seeing SLF4J log messages in my console output. So thanks again.

For completeness sake, here is my final (and working) jboss-deployment-structure.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <module name="deployment.jboss-forge-html5">
        <resources>
            <resource-root path="WEB-INF/lib/shared-1.1-SNAPSHOT.jar">
                <filter>
                    <exclude path="org/slf4j" />
                </filter>
            </resource-root>
        </resources>
    </module>
</jboss-deployment-structure>

You do know that this jboss-deployment-structure.xml effectively does noting for your deployment.

if you delete it it would be the same.

[rustydee]

Tomaz Cerar wrote:

You do know that this jboss-deployment-structure.xml effectively does noting for your deployment.

if you delete it it would be the same.

OK - that's quite a bold assertion, but it does seem to be true. So now I'm really confused.

If it does nothing, what's the point in having it, and why have the previous posts suggested it? Are you able to let us know where you get your information from?

As to why it wasn't working, then it was, and now it still is - I'm not sure. I've been trying lots of combinations of things, and I've probably got everything messed up with my 'test' project. So, my 'test' project is outputting SLF4J log messages, whereas my 'real' one isn't. Sigh!

[rustydee]

So I've been playing around with this for quite a few days now, but it appears as though I've made a breakthough. From looking at the DEBUG log files that Wildfly procduces, it looks as though the SLF4J module was being loaded and 'assigned' to my war. BUT, I still wasn't getting any log output. Eventually, what I've had to do is disable the logging system in the jboss-deployment-structure.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
  <deployment>
    <exclude-subsystems>
        <subsystem name="logging" />
    </exclude-subsystems>
  </deployment>
</jboss-deployment-structure>

It's possible that some of my other settings are combining to actually make this work (like specifying an org.slf4j dependency for the manifest entry in the maven war plugin), but this was the change that allowed me to actually see my log messages on the console. I may go back and investigate further, but for now I'm exhausted by this and taking a break.

[jamezp]

Honestly it's really not that difficult. SLF4J is a logging facade and requires a binding implementation. To use SLF4J with WildFly all you need to do is use it and not bring in the SLF4J API into your deployment. Both the API and binding implementation are provided by the server. No jboss-deployment-structure.xml is needed and there's not need to mess with the add-logging-api-dependencies default value.

Things to look at if that isn't working is check your deployment for a log4j.xml or a log4j.properties file. Make sure you don't have another slf4j binding implementation packaged in your deployment. Other than that it should work fine.

--

James R. Perkins

[teknopaul]

James R. Perkins reply is only an acceptable answer if you want to accept JBoss's implementation below slf4j, and don't have any opinion on logging, and are willing to accept JBoss defaults. Which includes only logging Strings, for example.

If you want to use your own appenders with slf4j as the API layer (which most apps do want) JBoss makes it hard by putting org.slf4j.impl.* on the classpath already, with a dumb implementation.

Using slf4j-api in code is normal, but you still want to control logging output.  Using JBoss makes this hard.  Fiddling with standalone config in CI env is also hard compared to adding an XML file to each EAR.

[jamezp]

Well slf4j is a logging facade. It has no concept of appenders. WildFly supplies an slf4j binding which binds to the JBoss Log Manager. If you want to use your own log manager it's quite easy to just exclude the logging subsystem. You then just need to include an slf4j-api library and a binder in your deployment.

--

James R. Perkins