-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixing ContextDataProvider
and ThreadContext
#2099
Comments
Shadowing always comes with caveats. If we fix/warn/document this for, say, |
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 [Although I am not entirely satisfied by those answers, since they are prepended by IANAL] |
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: