28 August 2007

My Soapbox for SLF4J

There seems to be a ruckus being generated lately over SLF4J. Both Howard and Dion have posted on the topic so far and they have their reasons. But I see that some things have been left out of the discussion, so I'll get on my soapbox for a bit to offer my own opinion.

IMO, the most important point about JCL is that the use of it is most oftentimes incorrect from an architecture standpoint, and this is according to the creator of JCL, Rod Waldhoff:

'...The purpose of Commons Logging is not to somehow take the logging world by storm. In fact, there are very limited circumstances in which Commons Logging is useful. If you're building a stand-alone application, don't use commons-logging. If you're building an application server, don't use commons-logging. If you're building a moderately large framework, don't use commons-logging. If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging framework they're going to want to use, then commons-logging might be useful to you...'

Here is Rod's full blog entry.

Additionally, back in 2004 Ceki posted an extremely good writeup about the shortcomings of JCL that addresses the classloader issues with JCL. Anyone who has ever been bitten by these issues has my sympathy because I've been there before as well. Even the latest Spring Framework project (Spring OSGi) doesn't use JCL. Instead, Spring-OSGi switched to SLF4J. My buddy Chris has a great blog entry about JCL classloader issues as well.

And using java.util.logging (JUL) is just not a good option. Sure it's baked into the core Java libraries, but it is a pain to reconfigure because there are really only two options: a) via the logging.properties file in the JRE, or b) by supplying system properties (-D) to the JVM. Why would I want to reconfigure logging for my entire JRE and I suppose I could supply even more system properties to the JVM but what PITA. And don't get me started about the JUL feature set lagging behind Log4J so horribly in the areas of formatters and handlers. This is exactly why the x4juli project was created.

SLF4J provides what the vast majority of people really wanted (and assumed they were getting) when they adopted JCL in their projects. That is, an abstraction layer for logging that allows you to plug in your logging framework of choice at deployment time. SLF4J statically binds to a particular logging implementation so that there is no automagic discovery for configuration. This gets around the whole JCL nightmare.

SLF4J also supports the MDC/NDC (Mapped Diagnostic Context/Nested Diagnostic Context) that are supported in Log4J. The trouble with using these from Log4J with JCL is that JCL won't let them through its facade. SLF4J also offers parameterized log messages which is a really nice feature. Though the FAQ explains it, here is some more info on parameterized logging.

OK, that's my soapbox for today. Maybe I'll add more to this later.


  1. Right on. This is the best high-level analysis on the subject of Java logging I've come across. Of course, your analysis is quite favorable so I am naturally biased. :-)

  2. I have been a long time user of log4j and was today evaluating slf4j, logback for my future use.
    Here are 2 major (& somewhat related) things I found lacking in my 3 hrs evaluation of slf4j.

    1. Why it does not use java 1.5 varargs construct for parameterized logging. Why be bogged down by java 1.4 features... This is supposed to be the thing of the future.... Contructing an Object[] for passing more than 2 parameterized args is painful if you have to do it all over your code.

    2. What about support for internationalization/localization of logging output? I guess the parameterized log methods could be extended to use varargs and java ResourceBundle and MessageFormat to provide runtime localization of log messages. This is needed in industrial strengths products.

    Lastly I was curious to know why slf4j is not licences under LGPL? logback seems to be LGPL. I don't want to get 2 sets of permissions form my Legal dept. for using slf4j & logback...

  3. Those would be very nice features to add to SLF4J. I think that you should jump on the SLF4J mailing lists and start discussing these points so that they can be added to future versions:


    The software will only expand through an open discussion with the user community.

    The reason SLF4J does not use the LGPL is because that license can very restrictive for some people. The license under which SLF4J has been released is far more open than the LGPL and compatible with the LGPL.

  4. java.util.logging is poorly designed. Specifically, logging.properties is terrible.

    However, you can configure it on application startup with custom Java code and then it's not so bad.

    Java needs to fix logging. This is a great example about how something so simple can be so complicated.

  5. Giovanni: Java Logging is fairly solid other than the configuration (or lack of) problem. For that need, see x4juli

  6. Slf4j is an awesome library, we implemented it in Red5 and it handles all of our logging and that of our libraries (which use jcl,juli,log4j) just fine. The only problem we've run into is with our webapps not having their own log factories, but Ceki is aware of it.

  7. > The only problem we've run into is
    > with our webapps not having their
    > own log factories, but Ceki is
    > aware of it.

    I don't follow what you mean by the above comment. Could you elaborate it a bit?

  8. I can do better than that, I can give you the link to the bug report
    The gist of it is that we need each "app" to have its own logger, independent of the main applications root log.