-
-
Notifications
You must be signed in to change notification settings - Fork 973
/
codes.html
executable file
·548 lines (441 loc) · 22.7 KB
/
codes.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
<!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 SLF4J is bound with<em>slf4j-log4j12.jar</em>
and <em>log4j-over-slf4j.jar</em> is also 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 SLF4J is bound with
<em>slf4j-jcl.jar</em> and <em>jcl-over-slf4j.jar</em> is also
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="replay">A number (N) of logging calls
during the initialization phase have been intercepted and are now
being replayed. These are suject to the filtering rules of the
underlying logging system.
</h3>
<p><span class="label">since 1.7.15</span> Logging calls made
during the initilization phase are recorded and replayed
post-inititilization. Note that the replayed logging calls are
subject to filtering by the underlying logging system.</p>
<p>In principle, replaying only occurs for apllications which are
already multi-threaded at the time the first logging call occurs.
</p>
<p>See also <a
href="#substituteLogger">substitute loggers</a>.</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>
<p>See also <a href="#replay">intercepted and replayed logging
calls</a>.</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://jira.qos.ch/browse/SLF4J-59">issue 59</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="log4j_version">java.lang.NoClassDefFoundError:
org/slf4j/event/LoggingEvent</h3>
<p>Logback-classic version 1.1.4 and later require slf4j-api
version 1.7.15 or later.
</p>
<p>With an earlier slf4j-api.jar in the classpath, attempting
introspection of a Logger instance returned by logback version
1.1.4 or later will result in a <code>NoClassDefFoundError</code>
similar to that shown below.
</p>
<pre class="prettyprint source">Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/event/LoggingEvent
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
at java.lang.Class.privateGetPublicMethods(Class.java:2571)
at java.lang.Class.getMethods(Class.java:1429)
at java.beans.Introspector.getPublicDeclaredMethods(Introspector.java:1261)
at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1122)
at java.beans.Introspector.getBeanInfo(Introspector.java:414)
at java.beans.Introspector.getBeanInfo(Introspector.java:161)
</pre>
<p>Placing <em>slf4j-api.jar</em> version 1.7.15 or later in the
classpath should solve the issue.</p>
<p>Note that this problem only occurs with logback version 1.1.4
and later, other bindings such as slf4j-log4j, slf4j-jdk14 and
slf4j-simple are unaffected.
</p>
<!-- ====================================================== -->
<script src="templates/footer.js" type="text/javascript"></script>
</div>
</body>
</html>