[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