On Tuesday 06 February 2007 10:25, Niclas Hedhman wrote:

What is the main (bulleted) differences between the two??

Well, I suddenly noticed that you have left for the "dark side" ;o) of LGPL. Totally unexpected, and pushes me away from it... Sorry. Cheers & Good Luck Niclas Hedhman

At 03:25 AM 2/6/2007, Niclas Hedhman wrote:

Hi,

I noticed that things are really progressing at LogBack, which is good. I also feel that browsing the docs, it is a lot of Log4J thinking in there, so instead of reading my eyes into blood, I thought I could just ask;

Thank you Niclas. Yes, logback is very much the continuation of previous work on log4j. Consider logback as log4j 2.0.

What is the main (bulleted) differences between the two??

See my "10 reasons to move to logback" presentation. It is available at: http://logback.qos.ch/10reasons.ppt Here is a quick summary of the presentation: - Logback is an improved version of log4j. It is the continuation of 10 years of work started in 1997 with log4j 0.x, then log4j 1.0.x, followed by log4j 1.1.x, log4j 1.2.x and log4j 1.3.x. - Given that logback is built on top of SLF4J, you can switch to a another logging system at will. - The new Joran configration API sits at the core of logback. - The Status API for accrued resilliance. Logback's status API enables internal error reporting in a simple yet powerful way without adding complexity. - Documentation: already good and getting better by the day. - Filtering API. If you can imagine it, logback can filter it. - Marker objets to color log statements for highly-specialized processing. - Access module: easy integration with access logs generated by Tomcat or Jetty - JMX: You can configure logback at runtime using Mbeans. - TDD: logback has been developped test first. Moreover, logback is available for production use, today.

What I am hoping to find is that LogBack has less tight integration between the parts, and allows for better hooks at various levels. I.e. support for an SPI that free of classloading problems, proper allowance of object instances instead of class references, events for SPI level changes and so on.

Log4j was already pretty extensible, logback is even better. What is it that you are trying to accomplish?

Also, what is your policy on OSGi support, especially in view of the many legacy APIs??

Logback-classic natively implements the SLF4J API. SLF4J strives to be OSGi friendly -- a feature inherited by logback by virtue of its reliance on SLF4J.

Not sure if you have seen Pax Logging, where I try to support every known API to route into a Log4J driven backend, and support the OSGi dynamism and reload of the Logging service, without killing the client bundles. If LogBack is more modular by design than Log4J, I would like to either integrate Pax Logging into this project, or vice versa, making LogBack driving the default Pax Logging service implementation instead of Log4J.

I've briefly looked at Pax Logging. However, as I don't use OSGi on a regular basis, I unfortunately don't have a feel for Pax Logging. However, looking at Pax Logging is high on my todo list. You might want to have a closer look at the interaction between SLF4J and logback. Given that logback is implemented in terms of SLF4J, client code does not to reference logback loggers but SLF4J loggers. It follows that the client only sees the SLF4J API, oblivious to the existence of logback.

Cheers Niclas

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