SLF4J warning or error messages and their meanings
The method
o.a.commons.logging.impl.SLF4FLogFactory#release
was invoked.
Given the structure of the commons-logging API, in particular
as implemented by SLF4J, the
o.a.commons.logging.impl.SLF4FLogFactory#release()
method should never be called. However, depending on the
deployment of commons-logging.jar files in your servlet
container, release()
method may be unexpectedly
invoked by a copy of
org.apache.commons.logging.LogFactory
class shipping
with commons-logging.jar.
This is a relatively common occurrence with recent versions of Tomcat, especially if you place jcl-over-slf4j.jar in WEB-INF/lib directory of your web-application instead of $TOMCAT_HOME/common/lib, where $TOMCAT_HOME stands for the directory where Tomcat is installed. In order to fully benefit from the stability offered by jcl-over-slf4j.jar, we recommend that you place jcl-over-slf4j.jar in $TOMCAT_HOME/common/lib without placing a copy in your web-applications.
Please also see bug #22.
Operation [suchAndSuch] is not supported in jcl-over-slf4j.
An UnsuportedOperationException
is thrown whenever
one of the protected methods introduced in JCL 1.1 are
invoked. These methods are invoked by LogFactory
implementations shipping with
commons-logging.jar. However, the LogFactory
implemented by jcl-over-slf4j.jar, namely
SLF4FLogFactory, does not call any of these methods.
If you observe this problem, then it is highly probable that you have a copy of commons-logging.jar in your class path overriding the classes shipping with jcl-over-slf4j.jar. Note that this issue is very similar in nature to the warning issued when the "o.a.commons.logging.impl.SLF4FLogFactory.release()" method is invoked, discussed in the previous item.
Failed to load class
org.slf4j.impl.StaticLoggerBinder
This error is reported when the
org.slf4j.impl.StaticLoggerBinder
class could not be
loaded into memory. This happens when no appropriate SLF4J
binding could be found on the class path. Placing one (and only
one) of slf4j-nop.jar, slf4j-simple.jar,
slf4j-log4j12.jar, slf4j-jdk14.jar or
logback-classic.jar on the class path should solve the
problem.
As of SLF4J version 1.6, in the absence of a binding, SLF4J will default to a no-operation (NOP) logger implementation.
You can download SLF4J bindings from the project download page.
Multiple bindings were found on the class path
SLF4J API is desinged to bind with one and only one underlying logging framework at a time. If more than one binding is present on the class path, SLF4J will emit a warning, listing the location of those bindings. When this happens, select the one and only one binding you wish to use, and remove the other bindings.
For example, if you have both slf4j-simple-1.6.1.jar and slf4j-nop-1.6.1.jar on the class path and you wish to use the nop (no-operation) binding, then remove slf4j-simple-1.6.1.jar from the class path.
Logging factory implementation cannot be null
This error is reported when the LoggerFactory
class could not find an appropriate binding. Placing one (and only
one) of slf4j-nop.jar, slf4j-simple.jar,
slf4j-log4j12.jar, slf4j-jdk14.jar or
logback-classic.jar on the class path should prove to be
an effective remedy.
Detected both log4j-over-slf4j.jar
AND slf4j-log4j12.jar on the class path, preempting
StackOverflowError
.
The purpose of slf4j-log4j12 module is to delegate or redirect
calls made to an SLF4J logger to log4j. The purpose of the
log4j-over-slf4j module is to redirect calls made to a log4j
logger to SLF4J. If both slf4j-log4j12.jar and
log4j-over-slf4j.jar are present on the class path, a
StackOverflowError
will inevitably occur immediately
after the first invocation of an SLF4J or a log4j logger.
Here is how the exception might look like:
Exception in thread "main" java.lang.StackOverflowError at java.util.Hashtable.containsKey(Hashtable.java:306) at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:36) at org.apache.log4j.LogManager.getLogger(LogManager.java:39) at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249) at org.apache.log4j.Category.<init>(Category.java:53) at org.apache.log4j.Logger..<init>(Logger.java:35) at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:39) at org.apache.log4j.LogManager.getLogger(LogManager.java:39) at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249) at org.apache.log4j.Category..<init>(Category.java:53) at org.apache.log4j.Logger..<init>(Logger.java:35) at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:39) at org.apache.log4j.LogManager.getLogger(LogManager.java:39) subsequent lines omitted...
As of SLF4J version 1.5.11, the code preempts the inevitable
stack overflow error by throwing an exception with details about
the actual cause of the problem. This is deemed to be better than
leaving the user wondering about the reasons of the
StackOverflowError
.
For more background on this topic see Bridging legacy APIs.
Detected
both jcl-over-slf4j.jar AND slf4j-jcl.jar on the class path,
preempting StackOverflowError
.
The purpose of slf4j-jcl module is to delegate or redirect
calls made to an SLF4J logger to jakarta commons logging
(JCL). The purpose of the jcl-over-slf4j module is to redirect
calls made to a JCL logger to SLF4J. If both
slf4j-jcl.jar and jcl-over-slf4j.jar are present
on the class path, then a StackOverflowError
will
inevitably occur immediately after the first invocation of an
SLF4J or a JCL logger.
Here is how the exception might look like:
Exception in thread "main" java.lang.StackOverflowError at java.lang.String.hashCode(String.java:1482) at java.util.HashMap.get(HashMap.java:300) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:67) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:289) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:69) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) subsequent lines omitted...
As of SLF4J version 1.5.11, the code preempts the inevitable
stack overflow error by throwing an exception with details about
the actual cause of the problem. This is deemed to be better than
leaving the user wondering about the reasons of the
StackOverflowError
.
For more background on this topic see Bridging legacy APIs.
Failed to load class "org.slf4j.impl.StaticMDCBinder"
This error indicates that appropriate SLF4J binding could not be found on the class path. Placing one (and only one) of slf4j-nop.jar, slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar on the class path should solve the problem.
MDCAdapter cannot be null
This error is reported when org.slf4j.MDC
class
has not been initialized correctly. Same cause and remedy as the
previously listed item.
SLF4J versions 1.4.0 and later requires log4j 1.2.12 or later
The trace level was added to log4j in version 1.2.12 released on August 29, 2005. The trace level was added to the SLF4J API in version 1.4.0 on May 16th, 2007. Thus, starting with SLF4J 1.4.0, the log4j binding for SLF4J requires log4j version 1.2.12 or above.
However, as reported in bug 68, in
some environments it may be difficult to upgrade the log4j
version. To accommodate such circumstances, SLF4J's
Log4jLoggerAdapter
will map the TRACE level as
DEBUG.
slf4j-api version does not match that of the binding
Mixing mixing different versions of slf4j artifacts can cause problems. For example, if you are using slf4j-api-1.5.5.jar, then you should also use slf4j-simple-1.5.5.jar, using slf4j-simple-1.4.2.jar will not work.
In general, you should make sure that the slf4j-api version matches that of the slf4j binding.
At initialization time, if SLF4J suspects that there may be a mismatch problem, it emits a warning about the said mismatch.
For the exact details of the version mismatch detection mechanism, please refer to the relevant entry in the FAQ.
Substitute loggers were created during the default configuration phase of the underlying logging system
Highly configurable logging systems such as logback and log4j
may create components which invoke loggers during their own
initialization. See issue lbcore-47 for a
typical occurrence. However, since the binding process with SLF4J
has not yet completed (because the underlying logging system was
not yet completely loaded into memory), it is not possible to
honor such logger creation requests, resulting in a
NullPointerException
.
To avoid this chicken-and-egg problem, SLF4J substitutes a no-operation logger factory during this initialization phase. However, the substitute loggers returned during this phase are not operational. They are nop implementations.
If any substitute logger had to be created, SLF4J will emit a warning listing such nop loggers. This warning is intended to let you know that you should not expect any logging output from these loggers.
The only way to obtain output from the listed loggers, is to isolate the components invoking these loggers and to exclude them from the default configuration. Both logback and log4j allow multi-step configuration. It follows that the problematic components should be configured in a second step separate from default configuration.
If you are not interested in the output from any of the substitute loggers, then no action is required on your part.