Getting Used to "Logback"

Introduction

Logback is a successor to the old school log4j. Logback constitues of 3 modules :

logback-core :  This module lays the groundwork for the other two modules.
logback-classic : Offers a native implementation of the SLF4J API.
logback-access : This log generated when a user accesses a web-page on a web server.

Logback-classic module requires the presence of slf4j-api.jar and logback-core.jar in addition to logback-classic.jar on the classpath. The logback-*.jar files are part of the logback distribution whereas slf4j-api-1.7.5.jar ships with SLF4J, a separate project.

Why use Logback?

According to me the striking feature of Logback are:

1. Faster, smaller, higher mileage.
2. Modular Architecture
3. Easily integrates with legacy systems.
4. Highly configurable.

You can find detailed list of advantages straight from the horses mouth here.

Logback configuration

The steps that logback follows for configuration are:

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.

If you are using Maven and if you place the logback-test.xml under the src/test/resources folder, Maven will ensure that it won't be included in the artifact produced. Thus, you can use a different configuration file, namely logback-test.xml during testing, and another file, namely, logback.xml, in production. The same principle applies by analogy for Ant.

Typical Logback xml

Appenders

Logback delegates the task of writing a logging event to components called appenders. There are different types of appenders that logback supports. Please see in the below diagram for the hierarchy of Appenders.

The one I used was RollingFileAppender. It gave me flexibility to choose the RollingPolicy and decide what should be the check point to roll over to new log file and what format should the old file be saved as.

Multiple Appenders

It is possible to have multiple file appenders in your application. This might be needed when you need to generate multiple log files based on your requirement. There is a one-to-one relation between files and appenders. 

My tryst with multiple file appenders was to ensure certain use-case log went into one log file and others were logged into another file. The key to this type of implementation is adding a filter as shown in the code below:

Logging Levels

The set of possible levels (TRACE, DEBUG, INFO, WARN and ERROR). The effective level for a given logger L, is equal to the first non-null level in its hierarchy, starting at L itself and proceeding upwards in the hierarchy towards the root logger. To ensure that all loggers can eventually inherit a level, the root logger always has an assigned level. By default, this level is DEBUG.


The below 2 examples from Logback website are self explanatory and clearly show how logging inheritance works.

Logger name	Assigned level	Effective level
root	DEBUG	DEBUG
X	none	DEBUG
X.Y	none	DEBUG
X.Y.Z	none	DEBUG

In above example, only the root logger is assigned a level. This level value, DEBUG, is inherited by the other loggers X, X.Y and X.Y.Z

Logger name	Assigned level	Effective level
root	DEBUG	DEBUG
X	INFO	INFO
X.Y	none	INFO
X.Y.Z	ERROR	ERROR

In the example above, the loggers root, X and X.Y.Z are assigned the levels DEBUG, INFO and ERROR respectively. Logger X.Y inherits its level value from its parent X.