J2EE. Central logging system. Yes or No?

By neokrates, written on April 15, 2008


  • Join date: 11-30-99
  • Posts: 224
View Counter:
Rate it
  • You parse your logs using?

    View Results

    Loading ... Loading ...
  • bodytext bodytext bodytext

Imagine, you have J2EE Project with many modules, which should actually log in the good configured manner. Just binding apache commons logging or log4j wouldn’t solve the problem. Each new project will repeat the same steps to activate the logging, and no central configuration could be implemented

Obvious solution

Develop the logging module and configure all other modules so that they refer it.

Problem: where to put the log4j.xml?

The problem is where should the log4j.xml be found.


  • in the ‘log’ project you created;
  • once per web application (not a module or service), if you have only one central webapp;
  • once per target system. That is, you have staging environment under you control;

You can put log4j.xml into each in some default location.

Case 1. Putting log4j.xml into you “log” service module

In this case log4j.xml is stored, distributed and deployed together with your module.


  • you can easely edit the log4j.xml in the development environment.


  • if your service is a jar and bound into many distributions/sub applications, you will have to make sure they are all up-to-date;

It may be a very big problem, depending of your project size and teams involved.

This case is good to begin with but will become a problem as you project grows. For large project it might be a killer, particularly during critical stages.

Case 2. One log4j per application

You put or generate log4j.xml so, that it appears only once per distribution. It is either a separate module or service, which has only one instance. All other modules will have to use it’s functionality.


  • You can easily edit the log4j.xml in the development environment.
  • You can deploy the newer web appliction with new logging configuration and it will instantly for all modules.


  • If one application should run under different environments, many versions of that application must be distributed, probably just because of log4j.xml. That might mean slight work overhead;
  • Some build logic must be present to support log4j.xml generation on-the-fly for all target platforms, if you deploy for many.

This is a good choice; particularly if someone does a build chain for you and process can be automated.

Case 3. One log4j per target system or platform

Imagine, you have some test and production systems and live cluster. There is one instance of log4j.xml per system. That is common for current enterprises, simply because the department that runs your products just has many other modules and products. It must hold the universal file and module structure just to be capable to maintain the platform.


  • Someone else does log4j configuration;
  • Fine-tuned and uniformed configurations scale good for any cluster size;


  • One change in you application may cause manual work on hundreds systems. Depends on level of automation of you ‘IT’ of course;
  • You team might be caught in the middle of something to may very important update on logging, because central system has changed;
  • Someone must always know the status of the log4j.xml files, just to ensure they are not out of sync or otherwise outdated;

This case works well for large clusters with good support from IT Department. It is particularly nice if good level of automation is present. Of course, it may easily turn into chaos, if control, overview or know-how is lost. Chain reaction can then stop one or many systems.


Each case can bring some advantages, depending on the system, resources and tasks you have. If you first consider the given advantages and disadvantages you can choose the solution, which solves your particular problems best.

Be Sociable, Share!


Be Sociable, Share!

Leave a Reply