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 [EMAIL PROTECTED] Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/ _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
