[slf4j-dev] Moving log4j-over-slf4j

[Sebastien Pennec]

Hi everybody,

As you might know, the log4j-over-slf4j module is a part of SLF4J. It is used to 
intercept calls to log4j and redirect them to the user-chosen implementation thanks 
to SLF4J abstraction layer.

Recently, I had to use this module in a fairly important project, that involved log4j 
calls from a web-app running under Tomcat. Since Tomcat uses Jakarta Commons Logging 
(JCL) as an abstraction layer, and redirects any call to log4j by default, the 
log4j-over-slf4j module was heavily used, as well as the jcl104-over-slf4j module.

Heavy use of these two modules shows that there is room for improvement in 
log4j-over-slf4j. For example, supporting the MDC calls, or direct use of the log4j 
Level class is required to allow easy replacement of the log4j jar. These 
improvements are not possible without making log4j-over-slf4j work more closely with 
a logging implementation.

I thought that modifying log4j-over-slf4j and integrating it into logback might be a 
better solution. This implies that log4j-over-slf4j module needs to be
removed from SLF4J. I would like to perform the actual removal from the repository 
within the next few days. It will be back, with many improvements, in the logback 
source repository as a logback module, under the name "log4j-bridge".

While log4j-over-slf4j can be used to redirect calls to any implementation used by 
SLF4J (e.g. logback, log4j, java.util.logging), only the JUL users will be affected 
by the removal of the module: those who were using log4j-over-slf4j to redirect to 
logback will have a tested and working solution at hand. Also, the removal of this 
module from SLF4J doesn't change anything to the core functionalities of the project. 
Users will still be able to use SLF4J as a logging facade and choose their 
implementation as they see fit.

Integrating log4j-over-slf4j into logback allows for many improvements. In practical 
terms, logback can now be seen as a drop-in replacement for log4j. I believe that 
logback can be considered as the next step in terms of logging functionality, and 
that adding built-in support for log4j calls will benefit many users.

The removal of the log4j-over-slf4j module from SLF4J should not impact existing 
users, in particular because the module did not work as expected with 
commons-logging. My proposed solution reduces usage scope but it has the immense 
advantage of offering a working solution. Otherwise, the SLF4J project will continue 
to be a lightweight facade to logging implementations.

Cheers,

Sébastien

-- 
Sébastien Pennec
sebastien at qos.ch

Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch/