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 nameAssigned levelEffective level
rootDEBUGDEBUG
XnoneDEBUG
X.YnoneDEBUG
X.Y.ZnoneDEBUG
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 nameAssigned levelEffective level
rootDEBUGDEBUG
XINFOINFO
X.YnoneINFO
X.Y.ZERRORERROR

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.

Comments

Post a Comment

Popular posts from this blog

Introduction to jQgrid

Introduction Why waste time in developing lists /customizing Liferay OOB search container to display data in tabular format. On top of that more often then not we end up coding for sorting of columns, pagination and formatting some data depending on their values. Trirand has come up with a jQuery plugin called jQgrid. jQgrid supports all of such ease. It provides a nice-looking grid with built-in features such as sorting, editing, search, drill-down, tree lists, and more. It is based upon jQuery and integrates well with Liferay.  The grid is dual-licensed under both the GPL and MIT licenses  (just like
Read more

jQgrid reload with new data

To reload a jQGrid with fresh data you need to set the data parameter on the grid and invoke reload on it. jQuery("#promotionsGrid").setGridParam({ 'data': newData}).trigger("reloadGrid"); Here newData is a JavaScript array with which I need to re-load the grid. The important thing here is that I had to place this statement just before the grid initialization code even though the reload was expected on change event of a text box. Without that there was simply no effect on my grid!
Read more

Rich Client based UI technologies- A Comparison of Thick Client UI tools

Rich Client v/s Thin Client Software developers face many difficult decisions when building new applications, not the least of which is graphical user interface. There are various graphical user interface technologies used, but broadly they can be classified as Rich Client User interfaces and the thin client or web based user interfaces. To understand them better let us look at the history of rich and thin clients. While the Rich client GUI applications would support high quality end-user experience with features such a drag-and-drop, perspectives, customization, high speed local processing; it has had a traditional disadvantage of high deployment and upgrade costs. It was becoming highly difficult and costly to deploy and upgrade these applications. Then came the thin clients or the Web based applications. Thin clients solved many of the deployment and upgrade problems, but that was not without a cost, the cost was in terms of functionality and capability. Thin clients, based on...
Read more