slf4j-site/src/site/pages/codes.html - platform/external/slf4j - Git at Google

 <!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="loggerNameMismatch">Detected logger
     name mismatch</h3>

     <p>Logger name mismatch warnings are printed only if the
     <code>slf4j.detectLoggerNameMismatch</code> system property is set
     to true. By default, this property is not set and no warnings will
     be printed even in case of a logger name mismatch.
     </p>

     <p><span class="label">since 1.7.9</span> The warning will
     be printed in case the name of the logger specified via a class
     passed as an argument to the
     <code>LoggerFactory.getLogger(Class)</code> method differs from
     the name of the caller as computed internally by SLF4J.
     </p>

     <p>For example, the following code snippet</p>

 <pre class="prettyprint source">package com.acme;
 import com.foo.Kangaroo;

 class <b>Fruit</b> {
   Logger logger = LoggerFactory.getLogger(<b>Kangaroo.class</b>);
 }</pre>

     <p>will result in the warning</p>

     <pre class="prettyprint source">SLF4J: Detected logger name mismatch. Given name: "com.foo.Kangaroo"; computed name: "com.acme.Fruit".</pre>

     <p>but only if <code>slf4j.detectLoggerNameMismatch</code> system
     property is set to true.</p>

     <p>No warning will be issued for the special case where the class
     in which the logger is defined is a super-type of the class
     parameter passed as argument. For example,</p>

     <pre class="prettyprint source">class A {
     Logger logger = LoggerFactory.getLogger(getClass());
 }
 class B extends A {
     // no mismatch warning will be issued when B is instantiated
     // given that class A is a super-type of class B
 }</pre>

     <p>If you come across a mismatch warning which cannot be
     explained, then you might have spotted a white elephant, that is a
     very rare occurrence where SLF4J cannot correctly compute the name
     of the class where a logger is defined. We are very interested to
     learn about such cases. If and when you spot an inexplicable
     mismatch, please do file a <a href="bug-reporting.html">bug
     report</a> with us.
     </p>

     <!-- ====================================================== -->

     <h3 class="doAnchor" name="StaticLoggerBinder">Failed to 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.&lt;clinit&gt;(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">&lt;dependencies>
   &lt;dependency>
     &lt;groupId> org.apache.cassandra&lt;/groupId>
     &lt;artifactId>cassandra-all&lt;/artifactId>
     &lt;version>0.8.1&lt;/version>

     &lt;exclusions>
       &lt;exclusion>
         &lt;groupId>org.slf4j&lt;/groupId>
         &lt;artifactId>slf4j-log4j12&lt;/artifactId>
       &lt;/exclusion>
       &lt;exclusion>
         &lt;groupId>log4j&lt;/groupId>
         &lt;artifactId>log4j&lt;/artifactId>
       &lt;/exclusion>
     &lt;/exclusions>

   &lt;/dependency>
 &lt;/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.&lt;init>(Category.java:53)
   at org.apache.log4j.Logger..&lt;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..&lt;init>(Category.java:53)
   at org.apache.log4j.Logger..&lt;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>
	<!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="loggerNameMismatch">Detected logger
	name mismatch</h3>

	<p>Logger name mismatch warnings are printed only if the
	<code>slf4j.detectLoggerNameMismatch</code> system property is set
	to true. By default, this property is not set and no warnings will
	be printed even in case of a logger name mismatch.
	</p>

	<p><span class="label">since 1.7.9</span> The warning will
	be printed in case the name of the logger specified via a class
	passed as an argument to the
	<code>LoggerFactory.getLogger(Class)</code> method differs from
	the name of the caller as computed internally by SLF4J.
	</p>

	<p>For example, the following code snippet</p>

	<pre class="prettyprint source">package com.acme;
	import com.foo.Kangaroo;

	class <b>Fruit</b> {
	Logger logger = LoggerFactory.getLogger(<b>Kangaroo.class</b>);
	}</pre>

	<p>will result in the warning</p>

	<pre class="prettyprint source">SLF4J: Detected logger name mismatch. Given name: "com.foo.Kangaroo"; computed name: "com.acme.Fruit".</pre>

	<p>but only if <code>slf4j.detectLoggerNameMismatch</code> system
	property is set to true.</p>

	<p>No warning will be issued for the special case where the class
	in which the logger is defined is a super-type of the class
	parameter passed as argument. For example,</p>

	<pre class="prettyprint source">class A {
	Logger logger = LoggerFactory.getLogger(getClass());
	}
	class B extends A {
	// no mismatch warning will be issued when B is instantiated
	// given that class A is a super-type of class B
	}</pre>

	<p>If you come across a mismatch warning which cannot be
	explained, then you might have spotted a white elephant, that is a
	very rare occurrence where SLF4J cannot correctly compute the name
	of the class where a logger is defined. We are very interested to
	learn about such cases. If and when you spot an inexplicable
	mismatch, please do file a <a href="bug-reporting.html">bug
	report</a> with us.
	</p>

	<!-- ====================================================== -->

	<h3 class="doAnchor" name="StaticLoggerBinder">Failed to 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>