Hello Ralph, Thank for you for your reply. Logback as the basis for log4j 2.0 is a larger step than what I had in mind. Implementation of the SLF4J API directly in log4j is a low-hanging fruit but having a significant positive impact on the java community, by virtue of de facto standardization.
IMHO, breaking 100% compatibility would be a reasonable price to pay given the benefits involved, namely convergence into a logging standard. SLF4J is a very stable API which has not changed incompatibly since version 1.0-beta5, released on August 2005. Client code compiled against SLF4J 1.0-beta5 will compile against any subsequent version. Client code compiled against SLF4J 1.0-beta5 will run with any subsequent version (runtime/binary compatibility). If we can reach an agreement, SLF4J-compliant log4j can be released within *days*. It can be named log4j 1.4 or log4j 2.0. If it were named 1.4, that version could form the base for log4j 2.0. I will respond to Scott's message separately. Ralph Goers wrote:
I would support this in 2.0. Work has yet to start on that though. I =20 don't see how 100% compatibility can be maintained anyway as the plan, =20= as I understand it, includes moving to a later minimum Java release =20 and removing deprecated classes. The questions I wonder about are: 1. It would be easier if the author of Logback :-) was willing to =20 donate it to Apache as the basis for Log4j 2.0. 2. Would the community be willing to accept it since it has major =20 differences with Log4j. Ralph
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
