[slf4j-dev] Merging Logger and MarkingLogger

[Ceki Gülcü]

At 04:03 PM 1/26/2006, Boris Unckel wrote:
>Hello Ceki,
>
> > I intend to merge methods in MarkingLogger back into Logger with the
> > understanding that the bindings for logging systems without marker
> > support would simply ignore the Marker data (as was the vase prior to
> > SLF4J 1.0beta8).
> >
> > Comments?
> >
>I am anxious to see LogBack - does the name have a meaning?

It's a word play on "look back". Logging is about hindsight or
looking back, hence LOGBack.

>What is the relationship to log4j 1.2.x, log4j1.3, current nlog4?

NLOG4J is a slightly modified version of log4j 1.2.8 with native
SLF4J support. LOGBack builds on my work on log4j 1.2 and 1.3 but
has a broader scope. It is also architectured differently. Anyway,
I will reveal more as the beast takes shape.

>Would it be enough to have "MarkingLogger extends Logger" ?
>In my oppinion for a valid decision one needs the behaviour of a
>MarkingLogger method. Is it possible to implement the MarkingLogger method
>with "NOP" or does this change the log output? Or in other words: Is it
>possible to implement slf4j for exisiting loggers without breaking the
>interface? This question is regarded to all wrapper classes too.

You can see latest tentative changes in Subversion. All the methods in
MarkingLogger were merged back into Logger and the MarkerLogger
interface was removed. Existing Logger adapters implement the new
methods by extending MarkerIgnoringBase. Methods in MarkerIgnoringBase
delegate to their non-marker equivalent, ignoring the marker data.

For example see:
http://svn.slf4j.org/viewcvs/slf4j/trunk/src/java/org/slf4j/Logger.java?rev=520&view=markup
http://svn.slf4j.org/viewcvs/slf4j/trunk/src/java/org/slf4j/impl/MarkerIgnoringBase.java?rev=528&view=markup
http://svn.slf4j.org/viewcvs/slf4j/trunk/src/java/org/slf4j/impl/NOPLogger.java?rev=525&view=auto

>At last:
>Many (most?) developers use an IDE with CodeCompletion (in MS terms
>IntelliSense). If I have an Interface with dozens of methods it is much more
>difficult to see what is possible with the interface.
>This happens in the "MarkingLogger extends Logger" case and the "Logger
>contains MarkingLogger" case.

The previous Logger interface was on the fat side, the merged
interface is twice as fat. However, I think the benefits outweigh the
inconveniences. The varargs feature introduced in JDK 1.5 would
radically reduce the fat but that's unfortunately not an option at
this time.


>Regards
>Boris

-- 
Ceki Gülcü