Open daniel-jasinski opened 10 months ago
@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?
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.
@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.
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.
@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.
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.