Skip to content
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

Search for service provider using context class loader as a fallback #365

Open
daniel-jasinski opened this issue Nov 9, 2023 · 5 comments

Comments

@daniel-jasinski
Copy link

We are using a custom class loader for loading our application classes, but delegate loading SLF4j to standard classloaders.
Because of this SLF4J cannot load our custom ServiceProvider.

A simple fix for such situations is to perform a fallback search for service providers using context class loader.

The solution provided here would fix the issue.

I could provide an implementation if necessary.

@ceki
Copy link
Member

ceki commented Nov 17, 2023

@daniel-jasinski If you wish the provider to be loaded by your custom class loader, why don't you have org.slf4j.LoggerFactory be loaded by your customer class loader or more generally have LoggerFactory and the provider be reachable by the same class loader?

@daniel-jasinski
Copy link
Author

In our setup only our classes are loaded by our classloader, third-party classes are loaded by standard class loaders. When those classes request the LoggerProvider, they cannot see our provider.

@ceki
Copy link
Member

ceki commented Nov 17, 2023

@daniel-jasinski What is the parent child relationship between the various class loaders? What is the delegation model?

Also note that SLF4J was created in order to avoid the pitfalls of Jakarta Commons Logging in particular its class loader problems.

In any case, my previous comments stands.

@daniel-jasinski
Copy link
Author

The relationship is similar to "child-first", we load "our" classes using our classloader and delegate all other classes to the parent.

The mechanism of SLF4J would work well if we were using one of the standard providers, but we are using a custom one that is loaded by our loader and all other classes (SLF4J and its other users) are loaded by the parent.

At the moment we have a bit of a workaround/hack. We analyzed which "non-our" classes use SL4FJ and we load them and all of the SLF$J classes using our loader. The code is very simple but conceptually it is ugly (to say the least) and not robust.

@LanaLkv
Copy link

LanaLkv commented Jan 29, 2024

@ceki in our use case, we would also highly appreciate the solution with context service loader in org.slf4j.LoggerFactory#findServiceProviders
This would allow us to use the slf4j 2.x in an OSGi environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants