apache
Mixing `ContextDataProvider` and `ThreadContext`
Description
Hi all, I just stumbled on an interesting behavior mixing ContextDataProvider and ThreadContext.
In short, my application is using a dependency that provides a custom ContextDataProvider through SPI, but in my application code I also use ThreadContext.
When bundling using the gradle shadowJar plugin, I didn't configured the plugin to merge the SPI files, thus only the custom ContextDataProvider was loaded in the uber JAR, and not the built-in ThreadContextDataProvider.
Although it makes sense from the ServiceLoader POV, I wonder if something can be done to make this behavior less subtle, some ideas:
- log4j2 could still mount the
ThreadContextDataProvider, even though is not registered through SPI - log4j2 could print a warning when using
ThreadContextbut noThreadContextDataProviderwas loaded - Perhaps adding some documentation here helps as well https://logging.apache.org/log4j/2.x/manual/extending.html#custom-contextdataprovider , although for the final users that are mixing libraries, this might not be obvious anyway
Configuration
Version: 2.22.0
Operating system: Linux
JDK: 21
Shadowing always comes with caveats. If we fix/warn/document this for, say, ThreadContextDataProvider, we should ideally repeat the same for dozens of other Log4j ServiceProviders too. What I would appreciate is a section to the extending page warning users against caveats of shadowing and guiding them how to safely collapse ServiceProviders and Log4j2Plugins.dat files using log4j-transformer. We should ideally share concrete examples for the market leaders (Gradle's shadowJar, flatten-maven-plugin, etc.) too. @slinkydeveloper, is this something you can contribute in a PR?
I would even make a separate page in the Developer's Guide for shading.
Shading has a lot of aspects, including a legal one. I would include a section that references some answers from LEGAL, e.g.:
[Although I am not entirely satisfied by those answers, since they are prepended by IANAL]
