[slf4j-dev] Reasons for the MarkingLogger/Logger merge

[Ceki Gülcü]

Hello all,

The question of markers have been previously debated on this list. I
believe that markers will be a very significant feature of future
logging systems but it's not easy to convince people of that when
there are no logging systems taking advantage of markers. However,
that will hopefully change after LOGBack is released to the wider
public.

You might be asking yourself why is the MakingLogger/Logger merge
necessary or even appropriate?

At present time, support for Marker objects may seem like unnecessary
clutter. However, if and when users start taking advantage of markers,
then the MarkingLogger/Logger separation would have caused a split
between logging systems supporting markers and those that do not
support them. I think it is undesirable to create two distinct logging
worlds, those with and those without marker support.

As the SLF4J API stands today, clients can easily switch between
various logging systems.  If logging systems supporting markers and
those that do not have distinct SLF4J APIs (MarkingLogger vs. Logger),
then SLF4J would obviously still allow switching within each logging
world but not *between* those two worlds.

You might suspect that the merge is a trick to force users to move to
LOGBack (which supports markers). Actually, the exact opposite is
true. The MarkingLogger/Logger merge will allow clients to switch
*back* to log4j, jdk 1.4 logging or to x4juli even if they invoke
marker specific logger operations in their code. As SLF4J of 1.0RC5,
once a client decides to use markers, they cannot easily switch back
to "older" logging systems, such as log4j or jdk 1.4 logging. The
latest changes now SLF4J's SVN repository are designed to let clients
to freely switch back and forth between logging systems regardless of
marker support. Freedom of choice is what SLF4J is supposed to provide
in the first place...

Comments?



-- 
Ceki Gülcü