The Logging Mess

September 13, 2011

Every application needs logging. And right now there are a lot of options on what exactly to use for logging in Java. The most famous frameworks are: log4j, logback, commons-logging, slf4j, java.util.logging. And there are a lot more – every now and then someone decides to write his own logger – just go to the Open Type dialog of your IDE and type “Logger” (not to mention that some use the name “Log”). And there’s also the ServletContext.log(..) and stuff like that. It is indeed a mess. But let’s start with some history (note: here’s another post on the topic) .

First there was System.out and System.err. But they were inflexible, so a need for a feature-rich logging has arisen (note that I was in elementary school at that time). Logging that can be customized format, that can go to multiple targets – files, consoles, emails, etc. So log4j has appeared – in 1999.

But other solutions spawned as well, including java.util.logging – an attempt to have standard JDK logging. Not a very successful attempt, as it turned out. java.util.logging appeared with JDK 1.4 in the beginning of 2002. A few months later the realized need for a common logging interface for all existing loggers resulted in apache common-logging.

The idea of commons-logging was viable – libraries should not force a particular logging implementation on applications that use them. So each logging implementation gets adapted to a common API which is used by the library – so a library does not use org.apache.log4j.Logger – it uses org.apache.commons.logging.Log, and it delegates to whatever logging framework exists on the classpath. That way your project can use multiple libraries and use a single logging configuration for all of them.

But commons-logging was not good enough. People say that it has caused more problems than it has solved. So the author of log4j – Ceki Gülcü created a new project – slf4j (Simple Logging Facade for Java) in 2005. It aims to be a better commons-logging.

Log4j has been widely used since 1999, but it was not good enough, so guess who created a new project – logback. It was Ceki Gülcü again. Why a new project? Well, combination of political reasons and old code base that needs replacing from the ground, I guess. Anyway, logback appeared in 2006. How it is better than log4j? Ceki explains here.

So back to present day – there are a lot of logging frameworks and two facades – commons-logging and slf4j. Every library uses a different one, and it’s a mess. Version mismatches, tons of Logger classes on the classpath. Maven succeeds at making this simpler by at least not allowing multiple versions of the same logging implementation, but that’s it. And if you don’t know all the history above and which framework is used for what, it is likely for your project to suffer from that mess.

What’s the solution? The best way, I think, is to use slf4j and logback. Why?

  • slf4j has bridges for many existing implementations. This means that you remove the log4j.jar and use the log4j-over-slf4j.jar – it has the same classes in the same package, only the implementation differs – it delegates to the current slf4j implementation in use. That way all libraries that use log4j (or any other bridged implementation) will work with your logback configuration. Unfortunately this doesn’t work quite well with java.util.logging, so you have to hope not to have too many libraries that have decided on a “minimal dependency footprint”.
  • logback is better than log4j (same author – newer implementation, learning from previous mistakes)
  • if a better framework than logback appears you can easily switch to it without changing your classes.

And finally, a word about the logging configuration. It should be external, in the same way (and the same location, preferably) as the other externalized project configurations. You should then load it based on a system “config.location” property.

(In a spring-based web-application there is Log4jWebConfigurer, but there isn’t LogbackWebConfigurer. Luckily, it is simple to write, and there are some existing implementations that are based on the log4j one. In your web.xml the logbackConfigLocation param should be: file://${config.lotation}/logback.xml)

Why something so simple became so complicated? Because it isn’t simple. There are too many factors that were not taken into account in the beginning, so they needed to be rectified later. It’s a good thing that there hasn’t been a major change in the field since 2006, so we can consider things stable.

If you find the content interesting, you can subscribe and get updates


 

11 Responses to “The Logging Mess”

  1. Nice survey! :) Thanks!

  2. There is a log4j.properties to logback.xml Translator as well – very useful indeed, sometimes you have to change a line or two but usually it do all the stuff for you.
    http://logback.qos.ch/translator/
    And something really important i have lost 2 hours because i haven’t read it:
    Let us begin by discussing the initialization steps that logback follows to try to configure itself:

    Logback tries to find a file called logback.groovy in the classpath.

    If no such file is found, logback tries to find a file called logback-test.xml in the classpath.

    If no such file is found, it checks for the file logback.xml in the classpath..

    If neither file is found, logback configures itself automatically using the BasicConfigurator which will cause logging output to be directed to the console.

  3. [...] وبلاگ Bozho مقالات فنی /* [...]

  4. I tend to agree except for one annoying point about logback: tooling support isn’t there nor does the project provide an XML Schema (or DTD) that existing tools could use. That’s frustrating and slows down adoption.

  5. I was frustrated by the lack or schema/dtd as well, but their explanation is that the configuration is too flexible to be covered by a schema. And in fact, it is rather straightforward configuration. Log4j didn’t have “schema” either.

  6. Well, I decided to just create an XSD today for logback.

    https://github.com/enricopulatzo/logback-XSD

  7. Wonderful. I’ll try it.

  8. I miss an external app to change *at runtime* level logging

    does any logging framework support this feature ?
    I made a WAR to implement it but I’d like a logging system that support changes ‘on-the-fly’

  9. Yup, all of them ;) logback, for example, has scan=”true” which allows runtime scanning for configuration changes

  10. [...] logback, commons-logging, slf4j y otros tipos de soluciones a cada cual más exótica. En este artículo se hace un repaso bastante completo de la historia del [...]

  11. I’m still unsatisfied with the slf4j/logback tandem. SLf4J being originally aimed at the implementation of log-agnostic libraries (rightly?) refuses (or renounces?) to deal with log4j style “Levels” (aka priorities) – which poses a problem for supporting levels determined at run time.
    Logback – which is therefore a better option for standalone projects – does support Levels and a few other bits and pieces left out of slf4j but still forces slf4j on you. So that you’re left with an ugly bicephalic logging facility. To top it all Logback’s Logger class is “final”.
    The only sound solution, IMHO, is to wrap it all in a clean façade. So I guess the topic is far from closed even 2 years after your insightful article.

Leave a Reply