[slf4j-dev] Proposal for SLF4J 2.0 Logger API

[Remko Popma]

Jo, would you mind starting a separate thread for that? Maybe with subject something like   “Allow arbitrary objects as MDC values in SLF4J 2.0”?

I’d like to keep this discussion focused on the Logger API. 

Thank you!
Remko.

> On Dec 18, 2019, at 16:48, Toolforger <toolforger at durchholz.org> wrote:
> 
> 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
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev