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.