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; 111 import com.foo.Kangaroo; 112 113 class <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 } 131 class 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.<clinit>(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"><dependencies> 233 <dependency> 234 <groupId> org.apache.cassandra</groupId> 235 <artifactId>cassandra-all</artifactId> 236 <version>0.8.1</version> 237 238 <exclusions> 239 <exclusion> 240 <groupId>org.slf4j</groupId> 241 <artifactId>slf4j-log4j12</artifactId> 242 </exclusion> 243 <exclusion> 244 <groupId>log4j</groupId> 245 <artifactId>log4j</artifactId> 246 </exclusion> 247 </exclusions> 248 249 </dependency> 250 </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.<init>(Category.java:53) 341 at org.apache.log4j.Logger..<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..<init>(Category.java:53) 347 at org.apache.log4j.Logger..<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
