public class SeparateLogbackSupport extends Object
SLF4JDelegatingLog relies on for bootstrapping
the separated Logback system when the time has come.
When an SLF4J implementation is detected at class initialization, no fancy
bootstrapping occurs. The detected implementation will just be used. This
behavior is compatible with version 1.0.x of the juli-to-slf4j
library.
When no SLF4J implementation is available right from the start, its bootstrapping will automatically be triggered as soon as it is detected.
This deferred bootstrapping is made of three steps, during which all loggers and logging events creations are blocked.
LoggerFactory is triggered, binds to the
StaticLoggerBinder of the Logback that is accessible only by the
Catalina class loader, which is a child class loaderLoggerFactory.getLogger(String)
For the bootstrapping process to properly block loggers and logging events
creations in multi-thraded environments, this implementation synchronizes
globally on the SLF4JDelegatingLog.class, exactly
as the facade SLF4JDelegatingLog instances do (and are supposed to
do).
The automatic bootstrap-time detection runs a check once every
log requests. The current thread
context class loader is compared
with the class loader that has loaded this SeparateLogbackSupport
class. When they start being different, then we conclude that the Catalina
classloader has been created. The Logback system is then initialized. As a
reminder, here is the difference between those two loaders:
$CLASSPATH environment variable that is built from scratch in
catalina.sh startup script, with the help of setenv.sh, if
any. The Jar files it contains should be in $CATALINA_HOME/bin or
$CATALINA_BASE/bin.$CATALINA_HOME/lib and $CATALINA_BASE/lib. Very few setups
diverge from this default configuration.Copyright © 2015–2017. All rights reserved.