[slf4j-dev] Moving log4j-over-slf4j

[Ceki Gülcü]

Hi Sebastien,

I just tested log4j-bridge as found in logback 0.7-SNAPSHOT and it works 
nicely. Actually, the migration of our sudoku application as well as the 
shop application which use log4j 1.3 to logback seems to work beautifully 
and without changing a single line of code.

Although it would have been nicer to keep the log4j bridge in SLF4J, I 
think should definably go with what works, instead of the more general 
approach which unfortunately does *not* work.

I'll remove slf4j-over-slf4j as a module for the next release of SLF4J.

Cheers,

At 09:08 PM 12/13/2006, you wrote:
>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/
>_______________________________________________
>dev mailing list
>dev at slf4j.org
>http://www.slf4j.org/mailman/listinfo/dev

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch