The Logging Mess

The Logging Mess

September 13, 2011

Every application needs logging. And right now there are a lot of optionson 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 lotmore – every now and then someone decides to write his own logger – just go tothe Open Type dialog of your IDE and type “Logger” (not to mention that someuse the name “Log”). And there’s also the ServletContext.log(..) and stuff likethat. 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 aneed for a feature-rich logging has arisen (note that I was in elementaryschool at that time). Logging that can be customized format, that can go tomultiple targets – files, consoles, emails, etc. So log4j has appeared – in 1999.

But other solutions spawned as well, including java.util.logging – anattempt to have standard JDK logging. Note a very successful attempt, as itturned out. java.util.logging appeared with JDK 1.4 in the beginning of 2002. Afew months later the realized need for a common logging interface for allexisting loggers resulted inapache common-logging.

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

But commons-logging was not good enough. People say that it has caused more problems thanit has solved. So the author of log4j –Ceki Gülcü created a new project – slf4j (SimpleLogging 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, soguess who created a new project – logback. It was Ceki Gülcü again. Why a newproject? Well, combination of political reasons and old code base that needsreplacing from the ground, I guess. Anyway, logback appeared in 2006. How it isbetter than log4j? Cekiexplains here.

So back to present day – there are a lot of logging frameworks and twofacades – commons-logging and slf4j. Every library uses a different one, andit’s a mess. Version mismatches, tons of Logger classes on the classpath. Mavensucceeds at making this simpler by at least not allowing multiple versions ofthe same logging implementation, but that’s it. And if you don’t know all thehistory above and which framework is used for what, it is likely for yourproject 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 beexternal, in the same way (and the same location, preferably) as the otherexternalizedproject 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 issimple to write, and there are some existing implementations that are based onthe 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 beena major change in the field since 2006, so we can consider things stable.