[slf4j-user] logging common data simply

Joachim Durchholz jo at durchholz.org
Sun Feb 26 08:48:47 CET 2017


On 26.02.2017 01:14, Shanholtz, Jeff wrote:
> Upon investigating MDC, I don’t think it’ll work very well for my
> scenario. I’m not looking for something that is essentially static or at
> least static over some period of time. I’m looking for more of a local
> variable/transient MDC concept.

MDC is thread-local, with child threads inheriting it from the parent.
I.e. it's sort-of global.

 > In other words, if I were to set MDC
> properties in one method and then call another method, that other method
> may want to log different values for the properties (or none of the
> properties for that matter).

Maybe you should talk a bit about how your GUIDs go in and out of scope. 
Since we don't know about that, we cannot make any useful proposals how 
to make them available to logging.

On a tangent, consider the case that some library you are calling is 
emitting log messages: Do you needs your GUIDs in these messages to find 
out which of them belong to the same context?
The MDC is the only option to in inject data into such log messages, 
because 3rd-party library know nothing about your GUIDs, or about your 
SLF4J wrapper.

> Unless there’s another way to approach my problem that doesn’t have the
> drawbacks I’m describing, I might be better off sticking with my wrapper
> approach

The wrapper is a typical code smell, that's why people are trying to 
find other solutions for you.
Your use case might be the 1% where it's justified anyway. I see vague 
signs that the wrapper might indeed be a solution, but that it *is* 
going to make your code inflexible in some ways.

> GuidLog.guids(xGuid, yGuid, zGuid, logger).info("My log message");

Where's the advantage over

   logger.info("{}/{}/{} My log message", xGuid, yGuid, zGuid)

?

If you have lots of debug logging, the wrapper approach will force lots 
of toString calls and multithreaded hashmap updates inside MDC.put even 
if the log level does not cover DEBUG, so the wrapper approach would be 
lower.

Regards,
Jo


More information about the slf4j-user mailing list