[logback-dev] LogBack progress

[Ceki Gülcü]

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