| <!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" /> |
| |
| <style> |
| h3.doAnchor { |
| border-top: 2px solid #888; |
| padding-top: 1ex; |
| } |
| </style> |
| </head> |
| <body onload="prettyPrint(); decorate();"> |
| <script type="text/javascript" src="js/prettify.js"></script> |
| <script type="text/javascript">prefix='';</script> |
| <script type="text/javascript" src="templates/header.js"></script> |
| <script type="text/javascript" src="js/jquery-min.js"></script> |
| <script type="text/javascript" src="js/decorator.js"></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 class="doAnchor" name="release">The method |
| <code>o.a.commons.logging.impl.SLF4FLogFactory#release</code> was |
| invoked. |
| </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 class="doAnchor" |
| name="unsupported_operation_in_jcl_over_slf4j">Operation |
| [suchAndSuch] is not supported in jcl-over-slf4j. |
| </h3> |
| |
| <p>An <code>UnsupportedOperationException</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 class="doAnchor" name="StaticLoggerBinder">Failedto load class |
| <code>org.slf4j.impl.StaticLoggerBinder</code></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 initializer 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 class="doAnchor" name="multiple_bindings">Multiple bindings |
| were found on the class path |
| </h3> |
| |
| |
| <p>SLF4J API is designed 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. |
| </p> |
| |
| <p>The list of locations that SLF4J provides in this warning |
| usually provides sufficient information to identify the dependency |
| transitively pulling in an unwanted SLF4J binding into your |
| project. In your project's pom.xml file, exclude this SLF4J |
| binding when declaring the unscrupulous dependency. For example, |
| <em>cassandra-all</em> version 0.8.1 declares both <em>log4j</em> |
| and <em>slf4j-log4j12</em> as compile-time dependencies. Thus, |
| when you include <em>cassandra-all</em> as a dependency in your |
| project, the <em>cassandra-all</em> declaration will cause both |
| <em>slf4j-log4j12.jar</em> and <em>log4j.jar</em> to be pulled in |
| as dependencies. In case you do not wish to use log4j as the the |
| SLF4J backend, you can instruct Maven to exclude these two |
| artifacts as shown next:</p> |
| |
| <pre class="prettyprint"><dependencies> |
| <dependency> |
| <groupId> org.apache.cassandra</groupId> |
| <artifactId>cassandra-all</artifactId> |
| <version>0.8.1</version> |
| |
| <exclusions> |
| <exclusion> |
| <groupId>org.slf4j</groupId> |
| <artifactId>slf4j-log4j12</artifactId> |
| </exclusion> |
| <exclusion> |
| <groupId>log4j</groupId> |
| <artifactId>log4j</artifactId> |
| </exclusion> |
| </exclusions> |
| |
| </dependency> |
| </dependencies></pre> |
| |
| <p><span class="label notice">Note</span> The warning emitted by |
| SLF4J is just that, a warning. Even when multiple bindings are |
| present, SLF4J will pick one logging framework/implementation and |
| bind with it. The way SLF4J picks a binding is determined by the |
| JVM and for all practical purposes should be considered random. As |
| of version 1.6.6, SLF4J will name the framework/implementation |
| class it is actually bound to.</p> |
| |
| <p>Embedded components such as libraries or frameworks should not |
| declare a dependency on any SLF4J binding but only depend on |
| slf4j-api. When a library declares a compile-time dependency on a |
| SLF4J binding, it imposes that binding on the end-user, thus |
| negating SLF4J's purpose. When you come across an embedded |
| component declaring a compile-time dependency on any SLF4J binding, |
| please take the time to contact the authors of said |
| component/library and kindly ask them to mend their ways.</p> |
| |
| <!-- ====================================================== --> |
| |
| <h3 class="doAnchor" name="version_mismatch">slf4j-api version |
| does not match that of the binding</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 class="doAnchor" name="null_LF">Logging factory implementation |
| cannot be null</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 class="doAnchor" name="log4jDelegationLoop">Detected both |
| log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path, |
| preempting <code>StackOverflowError</code>. |
| </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 class="doAnchor" name="jclDelegationLoop">Detected both |
| jcl-over-slf4j.jar AND slf4j-jcl.jar on the class path, preempting |
| <code>StackOverflowError</code>. |
| </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 class="doAnchor" name="no_static_mdc_binder">Failed to load |
| class "org.slf4j.impl.StaticMDCBinder"</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 class="doAnchor" name="null_MDCA">MDCAdapter cannot be null |
| </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 class="doAnchor" name="log4j_version">SLF4J versions 1.4.0 and |
| later requires log4j 1.2.12 or later</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 class="doAnchor" name="substituteLogger" >Substitute loggers |
| were created during the default configuration phase of the |
| underlying logging system</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/LOGBACK-127">LOGBACK-127</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.</p> |
| |
| <p>To avoid this chicken-and-egg problem, SLF4J creates substitute |
| loggers during this phase (initialization). Calls made to the |
| substitute loggers during this phase are simply dropped. After the |
| initialization completes, the substitute logger will delegate |
| logging calls to the appropriate logger implementation and |
| otherwise will function as any other logger returned by |
| <code>LoggerFactory</code>. |
| </p> |
| |
| <p>If any substitute logger had to be created, SLF4J will emit a a |
| listing of such loggers. This list is intended to let you know |
| that any logging calls made to these loggers during initialization |
| have been dropped. |
| </p> |
| |
| |
| <script src="templates/footer.js" type="text/javascript"></script> |
| </div> |
| |
| </body> |
| </html> |