[36] Override the ThreadContextMap in the provider.

[jamezp]

resolves #36

[sschulze]

Looks pretty good to me. Just two remarks:

• in org.apache.logging.log4j.spi.Provider#loadThreadContextMap() is some logic with the classloader provided in the constructor. I'm not familiar enough with classloader kungfu, but is this a problem?
• As you already mentioned in your PR, the isEmpty() and getCopy() method is called very often in org.jboss.logmanager.log4j.JBossLogger#logMessage(...), so they are quite performance critical.

[dmlloyd]

I would suggest that we consider adding an MDC.isEmpty query method to avoid the overhead of the copy in this case.

[jamezp]

Makes sense, I filed https://issues.redhat.com/browse/LOGMGR-327 and will send up a PR.

[sschulze]

I just recognized, that previously it was ok to call ThreadContext.put("foo", null) (because DefaultThreadContextMap uses a java.lang.HashMap internally) but now this fails with a NPE.
It's not declared in the JavaDoc of MdcProvider but I checked three different implementations and they all contain null-checks resulting usually in a NPE.

[dmlloyd]

I think we can safely treat this case equivalently to MDC.remove("foo").

[dmlloyd]

I would use Map.copyOf(copy). This way, if we ever change MDC.copy() to return an immutable map, this won't actually have to make a copy.

[jamezp]

Yes, we just need to require Java 11 first. We're currently targeting Java 8.

[jamezp]

I changed the approach on this since we're going to do this requiring JBoss Log Manager 3.x. I've implemented a MDCProvider and an NDCProvider which are instead backed by the ThreadContext.

[jamezp]

Never mind, this new approach only works if the log4j2-jboss-logmanager is the only delegating log manager. We can't replace MDC and NDC like this.