SLF4J + logback + JBoss 7?

Question

Has anyone got SLF4J / logback to work with JBoss 7?

Previously, I was able to get my app to work in JBoss 5.1 by putting my "logback.groovy" in [server]/conf, and the logback core, classic (0.9.28), and Groovy (1.8.0) JARs in [server]/lib.

For JBoss 7.0.1, I've got the Groovy and logback modules set up OK (the .index files have been created), my EAR's MANIFEST.MF declares dependencies on both modules, and my "logback.groovy" is deployed in my WAR module's WEB-INF/classes, within my EAR. The EAR definitely deploys OK - lights are green...

Despite this, the only logging rules that actually get applied are the standard console/server.log ones set up in "standalone.xml". Yes, I can see my log statements (so SLF4J is working), but my logback rules, appenders, etc. are being ignored. There are no references to either logback or Groovy in any of that logging, so I'm assuming that I've not done enough to trigger logback's loading and finding my script.

There are other things I could try, but it would be good to know if other people have tried this. If they haven't, perhaps that's a sign that I should just throw in my lot with JBoss Logging?

Solution 1

JBoss AS7 uses the jboss-logmanager. I assume that logback appenders would require a log manger that can handle them. I'm not really sure what would happen if you switched out the log manager.

There is support for custom java.util.logging.Handler's so you could write a wrapper for an appender in a handler. I know it's probably not ideal, but it should work.

I would encourage anyone to use JBoss Logging and not just because I work on it :-) It really does have some nice features, like var-arg log methods which is what drew me to it in the first place. There is also support for i18n logging and messages through interfaces.

Also JBoss Logging is more than just an API. It's a full logging framework. In the next release of JBoss Logging we will offer a way to specify which log manager you would like to use. That might make something like this a bit easier, but I must admit I have not tested in in AS7. If I get the time I will though.

Solution 2

Are you sure logback is active? If logback cannot find a configuration file, i.e. logback.groovy or logback.xml, it will print a warning message on the console. The output should be similar to:

12:49:22,078 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
12:49:22,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.xml]
12:49:22,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Setting up default configuration.

Do you see any such output on the console? If not, assuming that Jboss 7 is bundled with an slf4j-binding, you are probably already using Jboss logging. (Your calls to the slf4j api are being sent to jboss logging instead of logback.)

The Jboss folks should be contacted about using a logging backend other than jboss-logging.

Digging a little further, I noticed that JAS7 ships with a file called slf4j-jboss-logmanager-1.0.0.GA.jar located under the ./modules/org/slf4j/impl/main/ folder. The contents of this file show that it is definitely an slf4j binding. I do not know how Jboss "modules" work but removing/disabling slf4j-jboss-logmanager is the way to go if you wish logback-classic to be picked up by slf4j.

Comments

[kostja]

Unfortunately, no. Tried using 7.1.1.Final but no success. Resources on the topic are still very scarce and go like this: "you really should use jboss.logging, other solutions are not supported. we will change that or even document the existing features if theres time, but there won't be time" :(

[bratan]

Tip: stackoverflow.com/questions/9518687/…

[Andrew Regan]

I'm afraid not - I had to drop logback and use JBoss Logging. There may be an answer, but I couldn't / didn't have time to find it. Does using the latest JBoss 7.1.x make any difference?

[Andrew Regan]

Thanks for this. I'm not seeing anything logback-related in the logs, so presumably logback just hasn't been instantiated. This seemed to happen automagically in my earlier setup, but perhaps now I need to do this programatically? Load the right class and the rest should follow? I'll have a try this evening and see how it goes. (Still a bit confused by the whole JBoss Logging thing: I'm told it's just an API, and that I can use the implementation of my choice, but there clearly is some kind of default impl. there, and it's in my way.)

[Ceki]

slf4j will bind with the first binding it finds. It will do so once per application start up. If slf4j binds with say, slf4j-simple.jar, logback-classic will never be instantiated as slf4j is already bound. If jboss-logging can also act as an slf4j binding, logback-classic will not be activated. Furhter investigation shows that slf4j-jboss-logmanager-1.0.0.GA.jar shipping with JAS7 is an slf4j binding.

[Andrew Regan]

Thanks, Ceki, I've changed the module.xml in JBoss's org.slf4j.impl:main to point to the logback classic and core JARs, instead of slf4j-jboss-logmanager. I then added a module for Groovy. Now, the logging is almost identical to before, but logback must have loaded, because I can see abbreviated classnames ('o.h.v.xml.ValidationXmlParser') and JAR names in stacktraces in the console.log. But no LoggerContext entries (no logback or Groovy messages whatsoever!), and my "logback.groovy" is still not used. Very strange.

[Andrew Regan]

P.S. I'll document all this properly when I finally get it all to work.

[Andrew Regan]

Thanks, jamezp, I've heard good things before about the i18n support. Would definitely be interested in the upcoming changes. If I can't fix the logback/groovy, I'll try converting that script into the right format for jboss-logmanager and give it a try. BTW, is jboss-logmanager free of the kind of (dead)locking issues that Log4J would get with multiple log files & lots of concurrent log entries? (stackoverflow.com/questions/7157507/…)

[James R. Perkins]

@AndrewRegan It should be free of dead locking for sure. It's our own implementation of the java.util.logging.LogManager.

[MaVRoSCy]

@James R. Perkins any thoughts for this question? stackoverflow.com/questions/11626897/…