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 <[email protected]> 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:[email protected]] On Behalf Of Joachim > Durchholz > Sent: Saturday, February 25, 2017 11:49 PM > To: [email protected] > 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 > [email protected] > http://mailman.qos.ch/mailman/listinfo/slf4j-user > _______________________________________________ > slf4j-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/slf4j-user > -- Matt Sicker <[email protected]>
_______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
