[slf4j-dev] Plan for SLF4J 2.0

[Joern Huxhorn]

On 08.03.2010, at 22:38, Gunnar Wagenknecht wrote:

> Am 06.03.2010 18:13, schrieb Ceki Gülcü:
>> If you are used to log4j's NDC, having NDC in SLF4J is more  
>> comfortable
>> than not having it. Otherwise, since MDC is semantically richer than
>> NDC (one can trivially implement NDC over MDC), one can always get by
>> using MDC instead of NDC. Another reason was that by scrapping NDC in
>> SLF4J there was one less piece of code to maintain.
>
> This might be a dump question. What does an NDC gives you that and MDC
> doesn't? AFAIK it's also important to keep the API for user simple and
> small. Especially multiple options should be avoided.
>

Please take a look at my examples:
http://sourceforge.net/apps/trac/lilith/wiki/NestedDiagnosticContext

Much like an ordinary stack-trace, the NDC is actually a stack. The  
stacking of messages is the key here.

The main difference between the MDC and (my implementation of) the NDC  
is that NDC is also supporting the same Message as the one I proposed  
for logging in general. This means, that the actual formatting of the  
message isn't performed if it's not really needed (for example, if the  
Appenders in Logback are not printing the NDC but choose to ignore it).

With MDC, on the other hand, one would have to format the message  
anyway.

Using only the MDC without any implementation of the NDC (like the one  
in slf4j-ext) would be quite awkward since the MDC does not have the  
stacked/ordered nature that NDC has.

It's quite similar to List vs. Map.
While a Map is very useful to map stuff ;) it's not an ideal  
collection for a sorted set, i.e. list.

> FWIW, I'd like to see an evolution to the Marker concept in a 2.0
> version. I sometimes have the feeling that the current  
> implementation is
> a bit over-engineered. Especially the difference around attached and
> detached markers and their intention can be confusing for clients. For
> example, sometimes they might share markers through static variables.
> Suddenly sombody elses attaches another marker to such a marker and  
> all
> other log messages are polluted as well. This has some hidden
> implications which I /personally/ don't like in APIs.

I also think that this is a shortcoming of the Marker concept but this  
can't be changed without breaking stuff.

>
> Frankly, I'd rather like to see a much smaller implementation. I often
> compare Markers with "tags". Everything is "tagged" these days. Thus,
> everything a marker needs is a good "#toString" method. :) Of course,
> then there needs to be some API to accept multiple "tags" per log  
> message.
>

Hm.

> -Gunnar
>

Cheers,
Joern.