In the past it was a good idea to use Thread.currentThread().getContextClassLoader() for loading implementation classes and resources.
Unfortunately this was dropped with #
LOGBACK-510
and #
LOGBACK-510
.
Due to that slf4j / logback can not be bundled as module in the wildfly server:
The Bilder is loaded via LoggerFactory.class.getClassLoader(); (in org.slf4j.LoggerFactory.findPossibleStaticLoggerBinderPathSet() )
=> so the one is loaded out of the logback.jars in wildfly module.
and the logger config files (logback.xml) are searched via getClassLoader of ch.qos.logback.classic.util.ContextInitializer via ch.qos.logback.core.util.Loader.getClassLoaderOfObject(Object)
where again only the module classloader is visible and so no logback.xml is found!
For EE environments that is wrong and the Thread.currentThread().getContextClassLoader() at that time points to the EAR classloader where the logback.xml is located.
Proposed solution is to first ask Thread.currentThread().getContextClassLoader() for resources/classes and only in fallback use the fix *.class classloaders.
|