[slf4j-user] logging common data simply

[Matt Sicker]

The line number solution in log4j is handled like this:
https://logging.apache.org/log4j/2.x/faq.html#logger-wrapper

On 27 February 2017 at 10:31, Shanholtz, Jeff <jeff.shanholtz at intel.com>
wrote:

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



-- 
Matt Sicker <boards at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20170227/7b363795/attachment.html>