| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd"> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> |
| <title>SLF4J Error Codes</title> |
| <link rel="stylesheet" type="text/css" media="screen" href="css/site.css" /> |
| <link rel="stylesheet" type="text/css" href="css/prettify.css" /> |
| </head> |
| <body onload="prettyPrint()"> |
| <script type="text/javascript" src="js/prettify.js"></script> |
| <script type="text/javascript">prefix='';</script> |
| |
| <script src="templates/header.js" type="text/javascript"></script> |
| <div id="left"> |
| <script src="templates/left.js" type="text/javascript"></script> |
| </div> |
| |
| |
| <div id="content"> |
| |
| <center> |
| <h2>SLF4J warning or error messages and their meanings</h2> |
| |
| </center> |
| |
| |
| <h3> |
| <a name="release" href="#release"> |
| The method |
| <code>o.a.commons.logging.impl.SLF4FLogFactory#release</code> |
| was invoked. |
| </a> |
| </h3> |
| |
| <p>Given the structure of the commons-logging API, in particular |
| as implemented by SLF4J, the |
| <code>o.a.commons.logging.impl.SLF4FLogFactory#release()</code> |
| method should never be called. However, depending on the |
| deployment of <em>commons-logging.jar</em> files in your servlet |
| container, <code>release()</code> method may be unexpectedly |
| invoked by a copy of |
| <code>org.apache.commons.logging.LogFactory</code> class shipping |
| with <em>commons-logging.jar</em>. |
| </p> |
| |
| <p>This is a relatively common occurrence with recent versions of |
| Tomcat, especially if you place <em>jcl-over-slf4j.jar</em> in |
| <em>WEB-INF/lib</em> directory of your web-application instead of |
| <em>$TOMCAT_HOME/common/lib</em>, where $TOMCAT_HOME stands for |
| the directory where Tomcat is installed. In order to fully benefit |
| from the stability offered by <em>jcl-over-slf4j.jar</em>, we |
| recommend that you place <em>jcl-over-slf4j.jar</em> in |
| <em>$TOMCAT_HOME/common/lib</em> without placing a copy in your |
| web-applications. |
| </p> |
| |
| <p>Please also see <a |
| href="http://bugzilla.slf4j.org/show_bug.cgi?id=22">bug |
| #22</a>.</p> |
| |
| <!-- ====================================================== --> |
| |
| <h3> |
| <a name="unsupported_operation_in_jcl_over_slf4j" href="#unsupported_operation_in_jcl_over_slf4j"> |
| Operation [suchAndSuch] is not supported in jcl-over-slf4j. |
| </a> |
| </h3> |
| |
| <p>An <code>UnsuportedOperationException</code> is thrown whenever |
| one of the protected methods introduced in JCL 1.1 are |
| invoked. These methods are invoked by <code>LogFactory</code> |
| implementations shipping with |
| <em>commons-logging.jar</em>. However, the <code>LogFactory</code> |
| implemented by <em>jcl-over-slf4j.jar</em>, namely |
| SLF4FLogFactory, does not call any of these methods. |
| </p> |
| |
| <p>If you observe this problem, then it is highly probable that you |
| have a copy of <em>commons-logging.jar</em> in your class path |
| overriding the classes shipping with |
| <em>jcl-over-slf4j.jar</em>. 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. |
| </p> |
| |
| <!-- ====================================================== --> |
| |
| <h3> |
| <a name="StaticLoggerBinder" href="#StaticLoggerBinder"> |
| Failedto load class |
| <code>org.slf4j.impl.StaticLoggerBinder</code> |
| </a> |
| </h3> |
| |
| <p>This error is reported when the |
| <code>org.slf4j.impl.StaticLoggerBinder</code> 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 <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>, |
| <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or |
| <em>logback-classic.jar</em> on the class path should solve the |
| problem. |
| </p> |
| |
| <p><span class="label">since 1.6.0</span> As of SLF4J version 1.6, in the absence of a binding, SLF4J |
| will default to a no-operation (NOP) logger implementation. |
| </p> |
| |
| <p>You can download SLF4J bindings from the project <a |
| href="http://www.slf4j.org/download.html">download page</a>. </p> |
| |
| <!-- ====================================================== --> |
| <!-- duplicates /faq.html#IllegalAccessError --> |
| |
| <!-- |
| <h3> |
| <a name="illegalAccess" href="#illegalAccess">java.lang.IllegalAccessError: tried to access field |
| org.slf4j.impl.StaticLoggerBinder.SINGLETON from class |
| org.slf4j.LoggerFactory</a> |
| </h3> |
| |
| <p>When this errors occurs, the exception looks as follows:</p> |
| <p class="source">java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON \ |
| from class org.slf4j.LoggerFactory |
| at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60) |
| ... </p> |
| |
| <p>The error is caused by the static initilizer of the |
| <code>LoggerFactory</code> class attempting to directly access the |
| SINGLETON field of |
| <code>org.slf4j.impl.StaticLoggerBinder</code>. While this was |
| allowed in SLF4J 1.5.5 and earlier, in 1.5.6 and later the |
| SINGLETON field has been marked as private access. |
| </p> |
| |
| <p>From a broader perspective, this issue is a manifestation of |
| problems encountered when mixing different versions of SLF4J |
| artifacts. Please also refer to the relevant <a |
| href="faq.html#compatibility">FAQ entry</a>. |
| </p> |
| --> |
| <!-- ====================================================== --> |
| <h3> |
| <a name="multiple_bindings" href="#multiple_bindings">Multiple |
| bindings were found on the class path</a> |
| </h3> |
| |
| |
| <p>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.</p> |
| |
| <p>When multiple bindings are available on the class path, select |
| one and only one binding you wish to use, and remove the other |
| bindings. For example, if you have both |
| <em>slf4j-simple-${version}.jar</em> and |
| <em>slf4j-nop-${version}.jar</em> on the class path and you wish |
| to use the nop (no-operation) binding, then remove |
| <em>slf4j-simple-${version}.jar</em> from the class path. If it is |
| not possible to remove the superflous bindings, SLF4J will still |
| bind with one logging framework/implementation. As of version |
| 1.6.6, SLF4J will name the framework/implementation class it is |
| actually bound to.</p> |
| |
| <p><span class="label notice">Note</span> The warning emitted by |
| SLF4J is just that, a warning. |
| </p> |
| |
| <!-- ====================================================== --> |
| <h3><a name="version_mismatch" href="#version_mismatch">slf4j-api |
| version does not match that of the binding</a></h3> |
| |
| <p>An SLF4J binding designates an artifact such as |
| <em>slf4j-jdk14.jar</em> or <em>slf4j-log4j12.jar</em> used to |
| <em>bind</em> slf4j to an underlying logging framework, say, |
| java.util.logging and respectively log4j. |
| </p> |
| |
| <p>Mixing mixing different versions of <em>slf4j-api.jar</em> and |
| SLF4J binding can cause problems. For example, if you are using |
| slf4j-api-${project.version}.jar, then you should also use |
| slf4j-simple-${project.version}.jar, using slf4j-simple-1.5.5.jar |
| will not work.</p> |
| |
| <p><span class="label notice">Note</span> From the client's |
| perspective all versions of slf4j-api are compatible. Client code |
| compiled with <em>slf4j-api-N.jar</em> will run perfectly fine |
| with <em>slf4j-api-M.jar</em> for any N and M. You only need to |
| ensure that the version of your binding matches that of the |
| slf4j-api.jar. You do not have to worry about the version of |
| slf4j-api.jar used by a given dependency in your project. You |
| can always use any version of <em>slf4j-api.jar</em>, and as long |
| as the version of <em>slf4j-api.jar</em> and its binding match, |
| you should be fine. |
| </p> |
| |
| <p>At initialization time, if SLF4J suspects that there may be a |
| api vs. binding version mismatch problem, it will emit a warning |
| about the suspected mismatch. |
| </p> |
| |
| |
| <h3> |
| <a name="null_LF" href="#null_LF">Logging factory implementation |
| cannot be null</a> |
| </h3> |
| |
| <p>This error is reported when the <code>LoggerFactory</code> |
| class could not find an appropriate binding. Placing one (and only |
| one) of <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>, |
| <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or |
| <em>logback-classic.jar</em> on the class path should prove to be |
| an effective remedy. |
| </p> |
| |
| <!-- ====================================================== --> |
| |
| <h3> |
| <a name="log4jDelegationLoop" |
| href="#log4jDelegationLoop">Detected both log4j-over-slf4j.jar |
| AND slf4j-log4j12.jar on the class path, preempting |
| <code>StackOverflowError</code>.</a> |
| </h3> |
| |
| <p>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 <em>slf4j-log4j12.jar</em> and |
| <em>log4j-over-slf4j.jar</em> are present on the class path, a |
| <code>StackOverflowError</code> will inevitably occur immediately |
| after the first invocation of an SLF4J or a log4j logger. |
| </p> |
| |
| <p>Here is how the exception might look like:</p> |
| |
| <pre class="prettyprint source">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...</pre> |
| |
| <p><span class="label">Since 1.5.11</span> SLF4J software 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 |
| <code>StackOverflowError</code>. |
| </p> |
| |
| <p>For more background on this topic see <a |
| href="legacy.html">Bridging legacy APIs</a>. |
| </p> |
| |
| <!-- ====================================================== --> |
| |
| |
| <h3> |
| <a name="jclDelegationLoop" href="#jclDelegationLoop">Detected |
| both jcl-over-slf4j.jar AND slf4j-jcl.jar on the class path, |
| preempting <code>StackOverflowError</code>.</a> |
| </h3> |
| |
| <p>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 |
| <em>slf4j-jcl.jar</em> and <em>jcl-over-slf4j.jar</em> are present |
| on the class path, then a <code>StackOverflowError</code> will |
| inevitably occur immediately after the first invocation of an |
| SLF4J or a JCL logger. |
| </p> |
| |
| <p>Here is how the exception might look like:</p> |
| |
| <pre class="prettyprint source">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...</pre> |
| |
| |
| <p><span class="label">Since 1.5.11</span> SLF4J software 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 |
| <code>StackOverflowError</code>. |
| </p> |
| |
| <p>For more background on this topic see <a |
| href="legacy.html">Bridging legacy APIs</a>. |
| </p> |
| |
| <!-- ====================================================== --> |
| |
| <h3> |
| <a name="no_static_mdc_binder" |
| href="#no_static_mdc_binder">Failed to load class |
| "org.slf4j.impl.StaticMDCBinder" |
| </a> |
| </h3> |
| |
| <p>This error indicates that appropriate SLF4J binding could not |
| be found on the class path. Placing one (and only one) of |
| <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>, |
| <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or |
| <em>logback-classic.jar</em> on the class path should solve the |
| problem. |
| </p> |
| |
| <h3> |
| <a name="null_MDCA" href="#null_MDCA">MDCAdapter cannot be null |
| </a> |
| </h3> |
| |
| <p>This error is reported when <code>org.slf4j.MDC</code> class |
| has not been initialized correctly. Same cause and remedy as the |
| previously listed item. |
| </p> |
| |
| |
| <h3><a name="log4j_version" href="#log4j_version">SLF4J versions |
| 1.4.0 and later requires log4j 1.2.12 or later</a></h3> |
| |
| <p>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. |
| </p> |
| |
| <p>However, as reported in <a |
| href="http://bugzilla.slf4j.org/show_bug.cgi?id=68">bug 68</a>, in |
| some environments it may be difficult to upgrade the log4j |
| version. To accommodate such circumstances, SLF4J's |
| <code>Log4jLoggerAdapter</code> will map the TRACE level as |
| DEBUG.</p> |
| |
| |
| <h3><a name="substituteLogger" href="#substituteLogger">Substitute |
| loggers were created during the default configuration phase of the |
| underlying logging system</a></h3> |
| |
| <p>Highly configurable logging systems such as logback and log4j |
| may create components which invoke loggers during their own |
| initialization. See issue <a |
| href="http://jira.qos.ch/browse/LBCORE-47">lbcore-47</a> 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 |
| <code>NullPointerException</code>.</p> |
| |
| <p>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. |
| </p> |
| |
| <p>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. |
| </p> |
| |
| <p>To obtain output from the listed loggers, isolate the |
| components invoking these loggers and to exclude them from the |
| default configuration. Once default configuration is finished, |
| those excluded components can be configured in a second-step |
| configuration. In principle, both logback and log4j allow |
| multi-step configuration. For logback, second-step configuration |
| is described in the <a |
| href="http://logback.qos.ch/manual/configuration.html#joranDirectly"> |
| relevant section.</a>. |
| </p> |
| |
| |
| |
| <p>If you are not interested in the output from any of the |
| substitute loggers, then no action is required on your part.</p> |
| |
| |
| |
| </div> |
| </body> |
| </html> |
| |