You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ThreadContext but no ThreadContextDataProvider was loaded
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?
Description
Hi all, I just stumbled on an interesting behavior mixing
ContextDataProvider
andThreadContext
.In short, my application is using a dependency that provides a custom
ContextDataProvider
through SPI, but in my application code I also useThreadContext
.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-inThreadContextDataProvider
.Although it makes sense from the
ServiceLoader
POV, I wonder if something can be done to make this behavior less subtle, some ideas:ThreadContextDataProvider
, even though is not registered through SPIThreadContext
but noThreadContextDataProvider
was loadedConfiguration
Version: 2.22.0
Operating system: Linux
JDK: 21
The text was updated successfully, but these errors were encountered: