You may want to be aware of the following stack overflow while experimenting the new juli-to-slf adapter on git:
.....
at org.apache.juli.logging.SLF4JLog.info(SLF4JLog.java:146)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1531)
// Log access to stopped classloader
if (!started) {
try

{ throw new IllegalStateException(); }

catch (IllegalStateException e)

{ log.info(sm.getString("webappClassLoader.stopped", name), e); <<<<<<<<<< }

}

at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1488)
public Class<?> loadClass(String name) throws ClassNotFoundException

{ return (loadClass(name, false)); }

at ch.qos.logback.classic.spi.PackagingDataCalculator.loadClass(PackagingDataCalculator.java:198)
at ch.qos.logback.classic.spi.PackagingDataCalculator.bestEffortLoadClass(PackagingDataCalculator.java:226)
at ch.qos.logback.classic.spi.PackagingDataCalculator.computeBySTEP(PackagingDataCalculator.java:132)
at ch.qos.logback.classic.spi.PackagingDataCalculator.populateUncommonFrames(PackagingDataCalculator.java:107)
at ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:99)
at ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:58)
at ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:100)
at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:126)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:471)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:427)
at ch.qos.logback.classic.Logger.info(Logger.java:647)
at org.apache.juli.logging.SLF4JLog.info(SLF4JLog.java:146)
...
I tought that Loggers were protected against reentrancy, but this is rather at the appender level
that the reentrancy flag is set/tested.
Globally the setup is:
slf4j api 1.6.1, logback core and classic (0.9.27), juli-over-slf4j.jar (build from git) in tomcat/bin,
with tomcat/bin/setenv.sh setting the classpath to these jars.
I don't yet understand why the tomcat classloader was not started; maybe because of a context reload.

I'll dig a bit more into that...