Search for service provider using context class loader as a fallback about slf4j HOT 5 OPEN

@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?

from slf4j.

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.

from slf4j.

@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.

from slf4j.

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.

from slf4j.

@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.

from slf4j.