[slf4j-user] logging common data simply

[Shanholtz, Jeff]

This is not a case where I want to inject "global" data into the logs. The guids are very much tied to the context of the code. For instance, all 3 guids might need to be logged at one point, then a method is called in which only the 1st guid is relevant. Once that method returns, it might be back to logging all 3 guids again. And no, I'm not concerned about calls to 3rd party libraries.

I agree that my wrapper isn't pretty which is the reason I started this topic.

You ask why is a wrapper better than just plain old logging? It is *marginally* better in that it forces a consistent log message format (important for importing into our ELK stack) and also serves as a reminder to the programmer to include the guids whenever possible.

Unfortunately Ceki's line number solution doesn't appear to apply. We're using log4j, not logback, and I haven't been able to find a similar log4j solution so far.

Thanks for the thoughts and ideas, everyone.

-----Original Message-----
From: slf4j-user [mailto:slf4j-user-bounces at qos.ch] On Behalf Of Joachim Durchholz
Sent: Saturday, February 25, 2017 11:49 PM
To: slf4j-user at qos.ch
Subject: Re: [slf4j-user] logging common data simply

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
_______________________________________________
slf4j-user mailing list
slf4j-user at qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user