Evolution of Logging – Log4J to SLF4J to Logback

Logging has always been a very important part of development. One of the current trends is to utilize a framework called SLF4J which takes the place of what commons logging intended to do. SLF4J can be used directly for logging or it can be the wrapper that allows other implementations to be plugged in under the covers. This would allow developers to code logging logic against the SLF4J API and add log4j.jar or logback.jar into the classpath and it would use these logging implementations for generating the logging statements. The following is an example of the simplistic changes that have to be made in order to use SLF4J:

 import org.slf4j.Logger; import org.slf4j.LoggerFactory;
    private static Logger logger = LoggerFactory.getLogger(Entity.class);

As far as the implementation is concerned, Log4J has been used for quite a while but it’s codebase is stagnant if not dead. In the last 5 years, there has only been a maintenance update. Another new framework has emerged that has been created by the creator of Log4J and it is called Logback. Logback makes many improvements over Log4J and it also simplifies much of the configuration. One of the more powerful features that I will not be taking advantage of is coding the configuration files using Groovy and having the ability to build conditional logging files based on environments or hosts.

Logback also adds additional capabilities to add simplicity and performance to the normal String concatenation that occurs through logging, such as:

 logger.info("{} has logged in", userID);

Instead of writing this as:

 logger.info(userId + " has logged in");

One of the other nice features is that when an exception is thrown, logback will attempt to identify in the log which jar file contains the class mentioned in that line of the stacktrace. This provides benefits for troubleshooting runtime issues.

Many frameworks or third party applications use other logging frameworks such as commons logging or Log4J. SLF4J provides jar files which are bridges for routing logging requests to from these frameworks onto the SLF4J framework. With the inclusion of the two logback-classic.jar and logback-core.jar, logback becomes that implementation. I will be using logback as the underlining implementation moving forward, as well as providing jcl-over-slf4j.jar and log4j-over-slf4j.jar to bridge the requests through SLF4J.

Another important part of the framework to understand is how logback loads its configuration files. There are two different types of files that can be provided, a logback.xml and a logback-test.xml. So in a maven project, I can supply both of these configurations (one to be used during production and one to use during unit testing.

The following is a code snippet that explains how logback searches for configuration files:


Logback can be configured either programmatically or with a configuration script expressed in XML or Groovy format. By the way, existing log4j users can convert their log4j.properties files to logback.xml using our PropertiesTranslator web-application.

Let us begin by discussing the initialization steps that logback follows to try to configure itself:

  1. Logback tries to find a file called logback.groovy in the classpath.
  2. If no such file is found, logback tries to find a file called logback-test.xml in the classpath.
  3. If no such file is found, it checks for the file logback.xml in the classpath..
  4. If neither file is found, logback configures itself automatically using the BasicConfigurator which will cause logging output to be directed to the console.

The fourth and last step is meant to provide a default (but very basic) logging functionality in the absence of a configuration file.

If you would like to read more, I have included resource links.





Share and Enjoy