Custom MDC Implementations?
Is it possible to write your own custom MDC implementation (similar to log4j's ContextDataProvider) so that logback can get context details from something other than threadlocal storage?
From: logback-user <logback-user-bounces@qos.ch> On Behalf Of Paul Galbraith via logback-user Sent: Tuesday, April 16, 2024 2:59 PM To: logback-user@qos.ch Cc: Paul Galbraith <paul@galbraiths.ca> Subject: [EXTERNAL] [logback-user] Custom MDC Implementations? Is it possible to write your own custom MDC implementation (similar to log4j's ContextDataProvider) so that logback can get context details from something other than threadlocal storage? --- Hi, I believe this is something I have done. One thing to note was to ensure that the MDC data is cleared as soon as it's irrelevant, especially in an application whereby user activity from a different application session might re-use that thread. This includes any exception handling that might report "something went wrong" to the use, or similar. What is it you are trying (not) to do? Thanks, Tim -- Tim Scott (he/him/his) OCLC * Lead Software Engineer cc: IT file
On 4/16/2024 3:59 PM, Paul Galbraith via logback-user wrote:
Is it possible to write your own custom MDC implementation (similar to log4j's ContextDataProvider) so that logback can get context details from something other than threadlocal storage?
Hi Paul, This is a recurrent request and in more recent versions of logback you may override the MDC implementation. To do this, you need 1) to set the custom mdcAppender in your own implementation of SLF4JServiceProvider and 2) by calling the setMdcAdapter() method of the loggerContext instance currently in use. Calling LoggerFactory.getILoggerFactory will return this instance. You probably have a handle on the loggerContext in your own implementation of SLF4JServiceProvider as mentioned in the previous point. An alternative under consideration, but not yet implemented, is to provide an extension point in SLF4J's mdcAdapter interface itself. There is a request in the SLF4J project (on github) where this is being discussed. You are welcome to add your voice. Here is the link https://github.com/qos-ch/slf4j/issues/399 Let us know how it goes, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 2024-04-17 8:51 a.m., Ceki Gulcu via logback-user wrote:
On 4/16/2024 3:59 PM, Paul Galbraith via logback-user wrote:
Is it possible to write your own custom MDC implementation (similar to log4j's ContextDataProvider) so that logback can get context details from something other than threadlocal storage?
Hi Paul,
This is a recurrent request and in more recent versions of logback you may override the MDC implementation.
To do this, you need
1) to set the custom mdcAppender in your own implementation of SLF4JServiceProvider
and
2) by calling the setMdcAdapter() method of the loggerContext instance currently in use. Calling LoggerFactory.getILoggerFactory will return this instance. You probably have a handle on the loggerContext in your own implementation of SLF4JServiceProvider as mentioned in the previous point.
An alternative under consideration, but not yet implemented, is to provide an extension point in SLF4J's mdcAdapter interface itself.
There is a request in the SLF4J project (on github) where this is being discussed. You are welcome to add your voice. Here is the link
https://github.com/qos-ch/slf4j/issues/399
Let us know how it goes,
Thanks Ceki, in this issue #399 it sounds like proposal #2 is in line with the approach that log4j has taken with it's ContextDataProvider interface which can be implemented and integrated via service discovery. I think this (proposal #2) would solve my problem nicely. I am trying to find a way to log scoped context from reactive frameworks like vert.x and Project Reactor where, similarly, request processing context is not at all framed by a time window on a single thread. I'm also not looking for any help from logback in identifying and propagating context, I just want a hook where I can do this myself. Probably context implementations for vert.x and Project Reactor could live nicely in a community extension repo of some sort. In the meantime I'll take a look at implementing SLF4JServiceProvider. Thanks for pointing me in the right direction. Paul
participants (3)
-
Ceki Gulcu -
Paul Galbraith -
Scott,Tim