1<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">
2<html xmlns="http://www.w3.org/1999/xhtml">
3<head>
4  <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
5  <title>SLF4J Error Codes</title>
6  <link rel="stylesheet" type="text/css" media="screen" href="css/site.css" />
7  <link rel="stylesheet" type="text/css" href="css/prettify.css" />
8
9  <style>
10    h3.doAnchor {
11      border-top: 2px solid #888;
12      padding-top: 1ex;
13    }
14  </style>
15</head>
16<body onload="prettyPrint(); decorate();">
17    <script type="text/javascript" src="js/prettify.js"></script>
18    <script type="text/javascript">prefix='';</script>
19    <script type="text/javascript" src="templates/header.js"></script>
20    <script type="text/javascript" src="js/jquery-min.js"></script>
21    <script type="text/javascript" src="js/decorator.js"></script>
22
23    <div id="left">
24      <script src="templates/left.js" type="text/javascript"></script>
25    </div>
26
27
28    <div id="content">
29
30    <center>
31      <h2>SLF4J warning or error messages and their meanings</h2>
32
33    </center>
34
35
36    <h3 class="doAnchor" name="release">The method
37    <code>o.a.commons.logging.impl.SLF4FLogFactory#release</code> was
38    invoked.
39    </h3>
40
41    <p>Given the structure of the commons-logging API, in particular
42    as implemented by SLF4J, the
43    <code>o.a.commons.logging.impl.SLF4FLogFactory#release()</code>
44    method should never be called. However, depending on the
45    deployment of <em>commons-logging.jar</em> files in your servlet
46    container, <code>release()</code> method may be unexpectedly
47    invoked by a copy of
48    <code>org.apache.commons.logging.LogFactory</code> class shipping
49    with <em>commons-logging.jar</em>.
50    </p>
51
52    <p>This is a relatively common occurrence with recent versions of
53    Tomcat, especially if you place <em>jcl-over-slf4j.jar</em> in
54    <em>WEB-INF/lib</em> directory of your web-application instead of
55    <em>$TOMCAT_HOME/common/lib</em>, where $TOMCAT_HOME stands for
56    the directory where Tomcat is installed. In order to fully benefit
57    from the stability offered by <em>jcl-over-slf4j.jar</em>, we
58    recommend that you place <em>jcl-over-slf4j.jar</em> in
59    <em>$TOMCAT_HOME/common/lib</em> without placing a copy in your
60    web-applications.
61    </p>
62
63    <p>Please also see <a
64    href="http://bugzilla.slf4j.org/show_bug.cgi?id=22">bug
65    #22</a>.</p>
66
67     <!-- ====================================================== -->
68
69    <h3 class="doAnchor" name="unsupported_operation_in_jcl_over_slf4j">Operation
70    [suchAndSuch] is not supported in jcl-over-slf4j.
71    </h3>
72
73    <p>An <code>UnsupportedOperationException</code> is thrown whenever
74    one of the protected methods introduced in JCL 1.1 are
75    invoked. These methods are invoked by <code>LogFactory</code>
76    implementations shipping with
77    <em>commons-logging.jar</em>. However, the <code>LogFactory</code>
78    implemented by <em>jcl-over-slf4j.jar</em>, namely
79    SLF4FLogFactory, does not call any of these methods.
80    </p>
81
82    <p>If you observe this problem, then it is highly probable that you
83    have a copy of <em>commons-logging.jar</em> in your class path
84    overriding the classes shipping with
85    <em>jcl-over-slf4j.jar</em>. Note that this issue is very similar
86    in nature to the warning issued when the
87    "o.a.commons.logging.impl.SLF4FLogFactory.release()" method is
88    invoked, discussed in the previous item.
89    </p>
90
91    <!-- ====================================================== -->
92    <h3 class="doAnchor" name="loggerNameMismatch">Detected logger
93    name mismatch</h3>
94
95    <p>Logger name mismatch warnings are printed only if the
96    <code>slf4j.detectLoggerNameMismatch</code> system property is set
97    to true. By default, this property is not set and no warnings will
98    be printed even in case of a logger name mismatch.
99    </p>
100
101    <p><span class="label">since 1.7.9</span> The warning will
102    be printed in case the name of the logger specified via a class
103    passed as an argument to the
104    <code>LoggerFactory.getLogger(Class)</code> method differs from
105    the name of the caller as computed internally by SLF4J.
106    </p>
107
108    <p>For example, the following code snippet</p>
109
110<pre class="prettyprint source">package com.acme;
111import com.foo.Kangaroo;
112
113class <b>Fruit</b> {
114  Logger logger = LoggerFactory.getLogger(<b>Kangaroo.class</b>);
115}</pre>
116
117    <p>will result in the warning</p>
118
119    <pre class="prettyprint source">SLF4J: Detected logger name mismatch. Given name: "com.foo.Kangaroo"; computed name: "com.acme.Fruit".</pre>
120
121    <p>but only if <code>slf4j.detectLoggerNameMismatch</code> system
122    property is set to true.</p>
123
124    <p>No warning will be issued for the special case where the class
125    in which the logger is defined is a super-type of the class
126    parameter passed as argument. For example,</p>
127
128    <pre class="prettyprint source">class A {
129    Logger logger = LoggerFactory.getLogger(getClass());
130}
131class B extends A {
132    // no mismatch warning will be issued when B is instantiated
133    // given that class A is a super-type of class B
134}</pre>
135
136    <p>If you come across a mismatch warning which cannot be
137    explained, then you might have spotted a white elephant, that is a
138    very rare occurrence where SLF4J cannot correctly compute the name
139    of the class where a logger is defined. We are very interested to
140    learn about such cases. If and when you spot an inexplicable
141    mismatch, please do file a <a href="bug-reporting.html">bug
142    report</a> with us.
143    </p>
144
145    <!-- ====================================================== -->
146
147    <h3 class="doAnchor" name="StaticLoggerBinder">Failed to load class
148    <code>org.slf4j.impl.StaticLoggerBinder</code></h3>
149
150    <p>This error is reported when the
151    <code>org.slf4j.impl.StaticLoggerBinder</code> class could not be
152    loaded into memory.  This happens when no appropriate SLF4J
153    binding could be found on the class path. Placing one (and only
154    one) of <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>,
155    <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or
156    <em>logback-classic.jar</em> on the class path should solve the
157    problem.
158    </p>
159
160    <p><span class="label">since 1.6.0</span> As of SLF4J version 1.6, in the absence of a binding, SLF4J
161    will default to a no-operation (NOP) logger implementation.
162    </p>
163
164    <p>You can download SLF4J bindings from the project <a
165    href="http://www.slf4j.org/download.html">download page</a>. </p>
166
167    <!-- ====================================================== -->
168    <!-- duplicates /faq.html#IllegalAccessError -->
169
170<!--
171    <h3>
172      <a name="illegalAccess" href="#illegalAccess">java.lang.IllegalAccessError: tried to access field
173      org.slf4j.impl.StaticLoggerBinder.SINGLETON from class
174      org.slf4j.LoggerFactory</a>
175    </h3>
176
177    <p>When this errors occurs, the exception looks as follows:</p>
178    <p class="source">java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON \
179     from class org.slf4j.LoggerFactory
180  at org.slf4j.LoggerFactory.&lt;clinit&gt;(LoggerFactory.java:60)
181  ... </p>
182
183    <p>The error is caused by the static initializer of the
184    <code>LoggerFactory</code> class attempting to directly access the
185    SINGLETON field of
186    <code>org.slf4j.impl.StaticLoggerBinder</code>. While this was
187    allowed in SLF4J 1.5.5 and earlier, in 1.5.6 and later the
188    SINGLETON field has been marked as private access.
189    </p>
190
191    <p>From a broader perspective, this issue is a manifestation of
192    problems encountered when mixing different versions of SLF4J
193    artifacts.  Please also refer to the relevant <a
194    href="faq.html#compatibility">FAQ entry</a>.
195    </p>
196-->
197
198    <!-- ====================================================== -->
199    <h3 class="doAnchor" name="multiple_bindings">Multiple bindings
200    were found on the class path
201    </h3>
202
203
204    <p>SLF4J API is designed to bind with one and only one underlying
205    logging framework at a time. If more than one binding is present
206    on the class path, SLF4J will emit a warning, listing the location
207    of those bindings.</p>
208
209    <p>When multiple bindings are available on the class path, select
210    one and only one binding you wish to use, and remove the other
211    bindings. For example, if you have both
212    <em>slf4j-simple-${version}.jar</em> and
213    <em>slf4j-nop-${version}.jar</em> on the class path and you wish
214    to use the nop (no-operation) binding, then remove
215    <em>slf4j-simple-${version}.jar</em> from the class path.
216    </p>
217
218    <p>The list of locations that SLF4J provides in this warning
219    usually provides sufficient information to identify the dependency
220    transitively pulling in an unwanted SLF4J binding into your
221    project. In your project's pom.xml file, exclude this SLF4J
222    binding when declaring the unscrupulous dependency. For example,
223    <em>cassandra-all</em> version 0.8.1 declares both <em>log4j</em>
224    and <em>slf4j-log4j12</em> as compile-time dependencies. Thus,
225    when you include <em>cassandra-all</em> as a dependency in your
226    project, the <em>cassandra-all</em> declaration will cause both
227    <em>slf4j-log4j12.jar</em> and <em>log4j.jar</em> to be pulled in
228    as dependencies. In case you do not wish to use log4j as the the
229    SLF4J backend, you can instruct Maven to exclude these two
230    artifacts as shown next:</p>
231
232    <pre class="prettyprint">&lt;dependencies>
233  &lt;dependency>
234    &lt;groupId> org.apache.cassandra&lt;/groupId>
235    &lt;artifactId>cassandra-all&lt;/artifactId>
236    &lt;version>0.8.1&lt;/version>
237
238    &lt;exclusions>
239      &lt;exclusion>
240        &lt;groupId>org.slf4j&lt;/groupId>
241        &lt;artifactId>slf4j-log4j12&lt;/artifactId>
242      &lt;/exclusion>
243      &lt;exclusion>
244        &lt;groupId>log4j&lt;/groupId>
245        &lt;artifactId>log4j&lt;/artifactId>
246      &lt;/exclusion>
247    &lt;/exclusions>
248
249  &lt;/dependency>
250&lt;/dependencies></pre>
251
252   <p><span class="label notice">Note</span> The warning emitted by
253   SLF4J is just that, a warning. Even when multiple bindings are
254   present, SLF4J will pick one logging framework/implementation and
255   bind with it. The way SLF4J picks a binding is determined by the
256   JVM and for all practical purposes should be considered random. As
257   of version 1.6.6, SLF4J will name the framework/implementation
258   class it is actually bound to.</p>
259
260   <p>Embedded components such as libraries or frameworks should not
261   declare a dependency on any SLF4J binding but only depend on
262   slf4j-api. When a library declares a compile-time dependency on a
263   SLF4J binding, it imposes that binding on the end-user, thus
264   negating SLF4J's purpose. When you come across an embedded
265   component declaring a compile-time dependency on any SLF4J binding,
266   please take the time to contact the authors of said
267   component/library and kindly ask them to mend their ways.</p>
268
269    <!-- ====================================================== -->
270
271    <h3 class="doAnchor" name="version_mismatch">slf4j-api version
272    does not match that of the binding</h3>
273
274    <p>An SLF4J binding designates an artifact such as
275    <em>slf4j-jdk14.jar</em> or <em>slf4j-log4j12.jar</em> used to
276    <em>bind</em> slf4j to an underlying logging framework, say,
277    java.util.logging and respectively log4j.
278    </p>
279
280    <p>Mixing mixing different versions of <em>slf4j-api.jar</em> and
281    SLF4J binding can cause problems. For example, if you are using
282    slf4j-api-${project.version}.jar, then you should also use
283    slf4j-simple-${project.version}.jar, using slf4j-simple-1.5.5.jar
284    will not work.</p>
285
286    <p><span class="label notice">Note</span> From the client's
287    perspective all versions of slf4j-api are compatible. Client code
288    compiled with <em>slf4j-api-N.jar</em> will run perfectly fine
289    with <em>slf4j-api-M.jar</em> for any N and M. You only need to
290    ensure that the version of your binding matches that of the
291    slf4j-api.jar. You do not have to worry about the version of
292    slf4j-api.jar used by a given dependency in your project. You
293    can always use any version of <em>slf4j-api.jar</em>, and as long
294    as the version of <em>slf4j-api.jar</em> and its binding match,
295    you should be fine.
296    </p>
297
298    <p>At initialization time, if SLF4J suspects that there may be a
299    api vs. binding version mismatch problem, it will emit a warning
300    about the suspected mismatch.
301    </p>
302
303    <!-- ====================================================== -->
304
305    <h3 class="doAnchor" name="null_LF">Logging factory implementation
306    cannot be null</h3>
307
308    <p>This error is reported when the <code>LoggerFactory</code>
309    class could not find an appropriate binding. Placing one (and only
310    one) of <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>,
311    <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or
312    <em>logback-classic.jar</em> on the class path should prove to be
313    an effective remedy.
314    </p>
315
316    <!-- ====================================================== -->
317
318    <h3 class="doAnchor" name="log4jDelegationLoop">Detected both
319    log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path,
320    preempting <code>StackOverflowError</code>.
321    </h3>
322
323    <p>The purpose of slf4j-log4j12 module is to delegate or redirect
324    calls made to an SLF4J logger to log4j. The purpose of the
325    log4j-over-slf4j module is to redirect calls made to a log4j
326    logger to SLF4J. If both <em>slf4j-log4j12.jar</em> and
327    <em>log4j-over-slf4j.jar</em> are present on the class path, a
328    <code>StackOverflowError</code> will inevitably occur immediately
329    after the first invocation of an SLF4J or a log4j logger.
330    </p>
331
332    <p>Here is how the exception might look like:</p>
333
334    <pre class="prettyprint source">Exception in thread "main" java.lang.StackOverflowError
335  at java.util.Hashtable.containsKey(Hashtable.java:306)
336  at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:36)
337  at org.apache.log4j.LogManager.getLogger(LogManager.java:39)
338  at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73)
339  at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249)
340  at org.apache.log4j.Category.&lt;init>(Category.java:53)
341  at org.apache.log4j.Logger..&lt;init>(Logger.java:35)
342  at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:39)
343  at org.apache.log4j.LogManager.getLogger(LogManager.java:39)
344  at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73)
345  at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249)
346  at org.apache.log4j.Category..&lt;init>(Category.java:53)
347  at org.apache.log4j.Logger..&lt;init>(Logger.java:35)
348  at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:39)
349  at org.apache.log4j.LogManager.getLogger(LogManager.java:39)
350  subsequent lines omitted...</pre>
351
352    <p><span class="label">Since 1.5.11</span> SLF4J software preempts
353    the inevitable stack overflow error by throwing an exception with
354    details about the actual cause of the problem. This is deemed to
355    be better than leaving the user wondering about the reasons of the
356    <code>StackOverflowError</code>.
357    </p>
358
359    <p>For more background on this topic see <a
360    href="legacy.html">Bridging legacy APIs</a>.
361    </p>
362
363    <!-- ====================================================== -->
364
365
366    <h3 class="doAnchor" name="jclDelegationLoop">Detected both
367    jcl-over-slf4j.jar AND slf4j-jcl.jar on the class path, preempting
368    <code>StackOverflowError</code>.
369    </h3>
370
371    <p>The purpose of slf4j-jcl module is to delegate or redirect
372    calls made to an SLF4J logger to jakarta commons logging
373    (JCL). The purpose of the jcl-over-slf4j module is to redirect
374    calls made to a JCL logger to SLF4J. If both
375    <em>slf4j-jcl.jar</em> and <em>jcl-over-slf4j.jar</em> are present
376    on the class path, then a <code>StackOverflowError</code> will
377    inevitably occur immediately after the first invocation of an
378    SLF4J or a JCL logger.
379    </p>
380
381    <p>Here is how the exception might look like:</p>
382
383    <pre class="prettyprint source">Exception in thread "main" java.lang.StackOverflowError
384  at java.lang.String.hashCode(String.java:1482)
385  at java.util.HashMap.get(HashMap.java:300)
386  at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:67)
387  at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249)
388  at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
389  at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:289)
390  at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:69)
391  at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249)
392  at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
393  subsequent lines omitted...</pre>
394
395
396    <p><span class="label">Since 1.5.11</span> SLF4J software preempts
397    the inevitable stack overflow error by throwing an exception with
398    details about the actual cause of the problem.  This is deemed to
399    be better than leaving the user wondering about the reasons of the
400    <code>StackOverflowError</code>.
401    </p>
402
403    <p>For more background on this topic see <a
404    href="legacy.html">Bridging legacy APIs</a>.
405    </p>
406
407    <!-- ====================================================== -->
408
409    <h3 class="doAnchor" name="no_static_mdc_binder">Failed to load
410    class "org.slf4j.impl.StaticMDCBinder"</h3>
411
412    <p>This error indicates that appropriate SLF4J binding could not
413    be found on the class path. Placing one (and only one) of
414    <em>slf4j-nop.jar</em>, <em>slf4j-simple.jar</em>,
415    <em>slf4j-log4j12.jar</em>, <em>slf4j-jdk14.jar</em> or
416    <em>logback-classic.jar</em> on the class path should solve the
417    problem.
418    </p>
419
420    <!-- ====================================================== -->
421
422    <h3 class="doAnchor" name="null_MDCA">MDCAdapter cannot be null
423    </h3>
424
425    <p>This error is reported when <code>org.slf4j.MDC</code> class
426    has not been initialized correctly. Same cause and remedy as the
427    previously listed item.
428    </p>
429
430    <!-- ====================================================== -->
431
432    <h3 class="doAnchor" name="log4j_version">SLF4J versions 1.4.0 and
433    later requires log4j 1.2.12 or later</h3>
434
435    <p>The trace level was added to log4j in version 1.2.12 released
436    on August 29, 2005. The trace level was added to the SLF4J API in
437    version 1.4.0 on May 16th, 2007. Thus, starting with SLF4J 1.4.0,
438    the log4j binding for SLF4J requires log4j version 1.2.12 or
439    above.
440    </p>
441
442    <p>However, as reported in <a
443    href="http://bugzilla.slf4j.org/show_bug.cgi?id=68">bug 68</a>, in
444    some environments it may be difficult to upgrade the log4j
445    version. To accommodate such circumstances, SLF4J's
446    <code>Log4jLoggerAdapter</code> will map the TRACE level as
447    DEBUG.</p>
448
449
450    <h3 class="doAnchor" name="substituteLogger" >Substitute loggers
451    were created during the default configuration phase of the
452    underlying logging system</h3>
453
454    <p>Highly configurable logging systems such as logback and log4j
455    may create components which invoke loggers during their own
456    initialization.  See issue <a
457    href="http://jira.qos.ch/browse/LOGBACK-127">LOGBACK-127</a> for a
458    typical occurrence. However, since the binding process with SLF4J
459    has not yet completed (because the underlying logging system was
460    not yet completely loaded into memory), it is not possible to
461    honor such logger creation requests.</p>
462
463    <p>To avoid this chicken-and-egg problem, SLF4J creates substitute
464    loggers during this phase (initialization). Calls made to the
465    substitute loggers during this phase are simply dropped. After the
466    initialization completes, the substitute logger will delegate
467    logging calls to the appropriate logger implementation and
468    otherwise will function as any other logger returned by
469    <code>LoggerFactory</code>.
470    </p>
471
472    <p>If any substitute logger had to be created, SLF4J will emit a a
473    listing of such loggers. This list is intended to let you know
474    that any logging calls made to these loggers during initialization
475    have been dropped.
476    </p>
477
478
479    <script src="templates/footer.js" type="text/javascript"></script>
480  </div>
481
482</body>
483</html>
484