[slf4j-dev] Plan for SLF4J 2.0

[Ceki Gülcü]

On 08/03/2010 10:38 PM, 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.
>
> 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.

Ouch. When multiple markers are needed, the idea is to pass the most specific 
marker as the argument to the logger request. This is rather counter-intuitive.

So if a request needs to be marked as CONFIDENTIAL and as DATABASE, you would 
create a new marker referencing both.

  Marker m = MarkerFactory.getMarker("COMBI");
  m.add(MarkerFactory.getMarker("CONFIDENTIAL"));
  m.add(MarkerFactory.getMarker("DATABASE"));

  logger.info(m, "Donald Duck withdrew 1'000 rupees");

adding a DATABASE marker to CONFIDENTIAL or the other way around would be quite 
wrong.

> 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.

I agree. The only elegant way I see for a log message to accept
multiple markers is to have an event to which markers are added. (The
user would progressively build the event to be logged.) Passing a marker
array or marker list before calling the logger is another possibility.

> -Gunnar
>