SLF4J currently uses services loader to find a implementation to bind (See https://github.com/ichttt/slf4j/blob/74ccf20fab1a35243ae41c2f56f2167e86afbd0c/slf4j-api/src/main/java/org/slf4j/LoggerFactory.java#L101)

This can cause issues with certain module classloading setups where the context classloader does not contain any module that has a slf4j implementation, but the classloader of the LoggerFactory class might be different from the context classloader and contain a module that has a slf4j implementation.

My suggestion would be to expand findServiceProviders so it also class ServiceLoader.load with the class loader of LoggerFactory (if it is different from the context classloader) and add this to the list as well.

This would not change existing behaviour if an implementation can be found with the context classloader, as slf4j always uses the first entry in the list returned by LoggerFactory.findServiceProviders.