[slf4j-dev] Plan for SLF4J 2.0

[Joern Huxhorn]

On 09.03.2010, at 17:00, Gunnar Wagenknecht wrote:

> Am 09.03.2010 12:20, schrieb Joern Huxhorn:
>> Much like an ordinary stack-trace, the NDC is actually a stack. The
>> stacking of messages is the key here.
>
> I know. But looking at your examples, I don't see something that the
> current Java stack trace wouldn't give me already. The logging of  
> method
> arguments might be key here but a stack only really makes sense if you
> use recursion. Another issue is that the API usage is quite  
> complicated
> for clients. They need to wrap each usage into try/finally blocks.

Well, it's not strictly necessary to wrap into try-finally since it's  
also possible to clear the NDC.
But my example is the only really fool-proof way that guarantees that  
the NDC is cleaned up both in case of normal leaving of the scope and  
in case of an exception.
The main difference between a normal stacktrace and an NDC is that the  
stacktrace says "I'm here (and there and there)" while the NDC would  
say "I'm doing this (while doing this and that)".

>
> However, I can see some value in having both - a simple to use MDC as
> well as an NDC. I wonder if it's possible to merge both into a central
> API "DiagnoseContext" or just DC.
>
>> 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).
>
> That's just an implementation detail. MDC can be changed as well.
> Remember, we are talking about a version 2.0 which means breaking API
> changes anyway.

That's not entirely true.

The way I planned it, switching to the new API is done simply by  
adding an ".n" to the package of Logger and LoggerFactory.
The rest of the API-changes are source-level-compatible.
This was a primary concern while doing it. I wanted to make it easy  
with three exclamation marks for people that want to switch over.  
Anything else wouldn't fly and would only serve to annoy people. Some  
people aren't very fond of changes and would rather stay with an old  
API instead of taking a look at a new one.

>
>> With MDC, on the other hand, one would have to format the message
>> anyway.
>
> Deferring formatting is good (performance wise). I think such a  
> message
> class (under the covers) should be a key concept in SLF4J 2.0.
>

It's actually a somewhat two-sided sword. Deferring the formatting  
should be postponed as much as possible but transforming arguments to  
Strings should be done early, i.e. definitely in the same thread at  
the time the logging call is made. Otherwise arguments might be  
changed until that transformation is done.

Cheers,
Joern.