Adapt log4j2.ThreadContext to jboss-logging.MDC

[sschulze]

Currently when using the Log4j2 frontend (log4j2-jboss-logmanager-1.1.1.Final) with the jboss-logging backend and calling log4j2.ThreadContext.put("foo", "bar") this invocation is not bridged towards the jboss-logging.MDC.

This specifically hits me in combination with Quarkus, reactive-messaging and smallrye-context-propagation, where it looks like only the jboss-logging.MDC is propagated but not the log4j2.ThreadContext.
Additionally I observed that context, that is put to the jboss-logging.MDC, is not rendered when the log message is created with the log4j-API.

I verified this by adding a very naive implementation of a MdcBridge, but this is probably not a candidate for an initial PR because it results in heavy use of MDC.getMap(), which is documented as "expensive and should be used sparingly". Additionally I had to cast the Map<String, Object> to Map<String, String>.

[jamezp]

This looks related to https://issues.redhat.com/browse/JBLOGGING-161.

The issue is likely that Quarkus is using the jboss-logmanger which binds the MDC to the jboss-logmanager and not log4j2.

[sschulze]

Not sure - as far as I know Quarkus uses jboss-logging internally, so it's probably totally fine that they use the jboss-logging.MDC.

If I get the idea of jboss-logging and for example the log4j2-jboss-logmanager right, it's just some kind of "Log4j2-lookalike frontend" which uses the "jboss-logging backend" for the real logging. Following this idea I'd expect that it shouldn't matter which frontend is used.
This is especially important when an application integrates multiple libraries and frameworks which possibly use different logging APIs.
But I'm not very familiar with jboss-logging yet and used SLF4J most of the time in the past for this kind of integration, so maybe it's just my misunderstanding of the jboss-logging ideas.

[jamezp]

What I meant was that the MDC in JBoss Logging would bind to the MDC in the JBoss Log Manager. I'd need to look, but maybe there is a way to delegate the ThreadContext to use org.jboss.logmanager.MDC. However, I'm not sure that is possible. The log4j ThreadContext is a final class so we can't extend it.

When the message is logged and the ExtLogRecord created, we do copy the ThreadContext data in. However, that doesn't propagate ThreadContext -> MDC.

@dmlloyd any specific thoughts on Quarkus here?

[sschulze]

For delegating the ThreadContext calls to jboss-logging.MDC I created an implementation of ThreadContextMap and registered this class in the log4j2.components.properties file. But because you already have the Provider in place, the provider can just implement the getThreadContextMap().

[jamezp]

So something like this? #37

It's not quite complete, but just a quick work up.

[sschulze]

I think there is a similar issue with the Log4j2 ThreadContextStack (ThreadContext.push(...)) and jboss-logging.NDC, but checking the ThreadContext code it looks like there is an injection mechanism missing for this SPI.
I filed an issue at Log4j2 but this probably takes some time waiting for Log4j2, so I think it's out-of-scope for this one :-)