[slf4j-dev] Proposal for SLF4J 2.0 Logger API

[Toolforger]

Am 17.12.19 um 20:36 schrieb Ceki:
>> If there is still time for SLF4J 2.0, I propose changing the Logger 
>> methods that take a String to accept an Object instead (excl. the 
>> methods that take format params); this enables various use cases and 
>> optimizations in SLF4J implementations that are not possible with the 
>> String-based API.
> 
> Yes, there is still time to make changes.

Heh. While we're at it, I have a similar suggestion to make: Allow 
arbitrary objects as MDC values, and possibly keys as well.

I had two use cases in the past:

1. I had enter/exit logging, and wanted to determine nesting depth in 
the Appender, for generating an indent (and the DatabaseAppender was 
supposed to link each message to its parent Enter message).
I had to keep the state in the MDC because that was the only thread-safe 
place I could find, and I had to serialize/deserialize the data. It 
sort-of worked, but it was ugly, and there were obvious inefficiencies. 
(There are more ramifications about nested log messages, it's probably 
smarter to directly support this in SLF4J. E.g. if an Enter message is 
not appended in its own right, it might still have to be if an inner 
message is appended.)

2. I had MDC objects that would usually not be logged, and that had an 
expensive toString() operation. I wanted to make the toString() call 
lazy and cache the result, but MDC does not accept anything but String, 
so that was just impossible.
(I can imagine workarounds. Like a weak reference map and storing just a 
key in the MDC value. Write a Formatter that substitutes not the value 
but the referenced object. It's complicated and error-prone, and 
Formatters don't compose easily, plus it's in the backend logger and not 
in SLF4J where it should be.)

Regards,
Jo