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@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
