Your feedback is requested
on changes under c
onsiderati
on for SLF4J versi
on 2
.1
.0
.
SLF4J warning or error messages and their meanings
No SLF4J providers were found
.
This message is a warning and not an error
. It is reported when no SLF4J providers could be found
on the class path
. SLF4J requires a logging provider because it is a logging API and not an logging implementati
on. Placing
one (and
only
one) of the many available providers such as slf4j-nop
.jar slf4j-simple
.jar, slf4j-reload4j
.jar, slf4j-jdk14
.jar or logback-classic
.jar
on the class path will solve the problem
.
In the absence of a provider, SLF4J will default to a no-operati
on (NOP) logger provider
.
Please note that slf4j-api versi
on 2
.0
.x and later use the ServiceLoader mechanism
. Earlier versi
ons relied
on the static binder mechanism which is no l
onger h
onored by slf4j-api
. Please read the FAQ entry What has changed in SLF4J versi
on 2
.0
.0? for further important details
.
If you are resp
onsible for packaging an applicati
on and do not care about logging, then placing slf4j-nop
.jar
on the class path of your applicati
on will get rid of this warning message
. Note that embedded comp
onents such as libraries or frameworks should not declare a dependency
on any SLF4J providers but
only depend
on slf4j-api
. When a library declares a compile-time dependency
on a SLF4J provider, it imposes that provider
on the end-user, thus negating SLF4J's purpose
.
Class path c
ontains SLF4J bindings targeting slf4j-api versi
ons 1
.7
.x or earlier
Planning for the advent of Jigsaw (
Java 9), slf4j-api versi
on 2
.0
.x and later use the ServiceLoader mechanism
. Earlier versi
ons of SLF4J relied
on the static binder mechanism which is no l
onger h
onored by slf4j-api versi
on 2
.0
.x
.
In case SLF4J 2
.x finds no providers targeting SLF4J 2
.x but finds instead bindings targeting SLF4J 1
.7 or earlier, it will list the bindings it finds but otherwise will ignore them
.
This can be solved by placing an SLF4J provider
on your classpath, such providers include logback versi
on 1
.3
.x and later, as well as
one of slf4j-reload4j, slf4j-jdk14, slf4j-simple versi
on 2
.0
.0 or later
.
See also the FAQ entry What has changed in SLF4J versi
on 2
.0
.0? for further important details
.
IllegalStateExcepti
on: org
.slf4j
.LoggerFactory in failed state
. Original excepti
on was thrown EARLIER
.
This IllegalStateExcepti
on is thrown post-initializati
on and informs the user that initializati
on of LoggerFactory has failed
.
Note It is important to realize that the excepti
on causing the
failure was thrown at an earlier stage
. This earlier excepti
on should provide more valuable informati
on about the root cause of the problem
.
The method o
.a
.comm
ons
.logging
.impl
.SLF4FLogFactory#release was invoked
.
Given the structure of the comm
ons-logging API, in particular as implemented by SLF4J, the o
.a
.comm
ons
.logging
.impl
.SLF4FLogFactory#release() method should never be called
. However, depending
on the
deployment of comm
ons-logging
.jar files in your servlet c
ontainer, release() method may be unexpectedly invoked by a copy of org
.apache
.comm
ons
.logging
.LogFactory class shipping with comm
ons-logging
.jar
.
This is a relatively comm
on occurrence with recent versi
ons of
Tomcat, especially if you place jcl-over-slf4j
.jar in WEB-INF/lib directory of your web-applicati
on instead of $
TOMCAT_HOME/comm
on/lib, where $
TOMCAT_HOME stands for the directory where
Tomcat is installed
. In order to fully benefit from the stability offered by jcl-over-slf4j
.jar, we recommend that you place jcl-over-slf4j
.jar in $
TOMCAT_HOME/comm
on/lib without placing a copy in your web-applicati
ons
.
Please also see bug #22
.
Operati
on [suchAndSuch] is not supported in jcl-over-slf4j
.
An UnsupportedOperati
onExcepti
on is thrown whenever
one of the protected methods introduced in JCL 1
.1 are invoked
. These methods are invoked by LogFactory implementati
ons shipping with comm
ons-logging
.jar
. However, the LogFactory implemented by jcl-over-slf4j
.jar, namely SLF4FLogFactory, does not call any of these methods
.
If you observe this problem, then it is highly probable that you have a copy of comm
ons-logging
.jar in your class path overriding the classes shipping with jcl-over-slf4j
.jar
. Note that this issue is very similar in nature to the warning issued when the "o
.a
.comm
ons
.logging
.impl
.SLF4FLogFactory
.release()" method is invoked, discussed in the previous item
.
Detected logger name mismatch
Logger name mismatch warnings are printed
only if the slf4j
.detectLoggerNameMismatch 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
.
since 1
.7
.9 The warning will be printed in case the name of the logger specified via a class passed as an argument to the LoggerFactory
.getLogger(Class) method differs from the name of the caller as computed internally by SLF4J
.
For example, the following code snippet
package com
.acme;
import com
.foo
.Kangaroo;
class Fruit {
Logger logger = LoggerFactory
.getLogger(Kangaroo
.class);
}
will result in the warning
SLF4J: Detected logger name mismatch
. Given name: "com
.foo
.Kangaroo"; computed name: "com
.acme
.Fruit"
.
but
only if slf4j
.detectLoggerNameMismatch system property is set to true
.
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,
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
}
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 bug report with us
.
Failed to load class org
.slf4j
.impl
.StaticLoggerBinder
This warning message is reported by slf4j-api versi
on 1
.7
.x and earlier when the org
.slf4j
.impl
.StaticLoggerBinder 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 slf4j-nop
.jar slf4j-simple
.jar, slf4j-log4j12
.jar, slf4j-jdk14
.jar or logback-classic
.jar
on the class path should solve the problem
.
If you are seeing this message, then you are NOT using slf4j-api versi
on 2
.0 or later but slf4j-api versi
on 1
.7
.x or earlier
. Slf4j-api versi
ons 2
.0
.x and later use the ServiceLoader mechanism
. Backends such as logback 1
.3 and later which target slf4j-api 2
.x, do not ship with org
.slf4j
.impl
.StaticLoggerBinder
. If you place a logging backend which targets slf4j-api 2
.0
.x, you need slf4j-api-2
.x
.jar
on the classpath
. See also relevant faq entry
.
since 1
.6.0 As of SLF4J versi
on 1
.6, in the absence of a binding, SLF4J will default to a no-operati
on (NOP) logger implementati
on.
If you are resp
onsible for packaging an applicati
on and do not care about logging, then placing slf4j-nop
.jar
on the class path of your applicati
on will get rid of this warning message
. Note that embedded comp
onents such as libraries or frameworks should not declare a dependency
on any SLF4J binding (or provider) but
only depend
on slf4j-api
. When a library declares a compile-time dependency
on a SLF4J binding (or provider), it imposes that binding (or provider)
on the end-user, thus negating SLF4J's purpose
.
Multiple bindings were found
on the class path
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 locati
on of those bindings
.
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 slf4j-simple-2
.0
.17
.jar and slf4j-nop-2
.0
.17
.jar
on the class path and you wish to use the nop (no-operati
on) binding, then remove slf4j-simple-2
.0
.17
.jar from the class path
.
The list of locati
ons that SLF4J provides in this warning usually provides sufficient informati
on 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, cassandra-all versi
on 0
.8
.1 declares both log4j and slf4j-log4j12 as compile-time dependencies
. Thus, when you include cassandra-all as a dependency in your project, the cassandra-all declarati
on will cause both slf4j-log4j12
.jar and log4j
.jar to be pulled in as dependencies
. In case you do not wish to use log4j as the SLF4J backend, you can instruct Maven to exclude these two artifacts as shown next:
<dependencies>
<dependency>
<groupId> org
.apache
.cassandra</groupId>
<artifactId>cassandra-all</artifactId>
<versi
on>0
.8
.1</versi
on>
<exclusi
ons>
<exclusi
on>
<groupId>org
.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusi
on>
<exclusi
on>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusi
on>
</exclusi
ons>
</dependency>
</dependencies>
Note The warning emitted by SLF4J is just that, a warning
. Even when multiple bindings are present, SLF4J will pick
one logging framework/implementati
on and bind with it
. The way SLF4J picks a binding is determined by the JVM and for all practical purposes should be c
onsidered random
. As of versi
on 1
.6.6, SLF4J will name the framework/implementati
on class it is actually bound to
.
Embedded comp
onents 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 comp
onent declaring a compile-time dependency
on any SLF4J binding, please take the time to c
ontact the authors of said comp
onent/library and kindly ask them to mend their ways
.
slf4j-api versi
on does not match that of the binding
An SLF4J binding designates an artifact such as slf4j-jdk14
.jar or slf4j-log4j12
.jar used to bind slf4j to an underlying logging framework, say,
java.util
.logging and respectively log4j
.
Mixing different versi
ons of slf4j-api
.jar and SLF4J binding (a
.k
.a
. provider since 2
.0
.0) can cause problems
. For example, if you are using slf4j-api-2
.0
.17
.jar, then you should also use slf4j-simple-2
.0
.17
.jar, using slf4j-simple-1
.5
.5
.jar will not work
.
Note From the client's perspective all versi
ons of slf4j-api are compatible
. Client code compiled with slf4j-api-N
.jar will run perfectly fine with slf4j-api-M
.jar for any N and M
. You
only need to ensure that the versi
on of your binding matches that of the slf4j-api
.jar
. You do not have to worry about the versi
on of slf4j-api
.jar used by a given dependency in your project
. You can always use any versi
on of slf4j-api
.jar, and as l
ong as the versi
on of slf4j-api
.jar and its binding match, you should be fine
.
At initializati
on time, if SLF4J suspects that there may be an api vs
. binding versi
on mismatch problem, it will emit a warning about the suspected mismatch
.
Logging factory implementati
on cannot be null
This error is reported when the LoggerFactory class could not find an appropriate binding
. Placing
one (and
only
one) of slf4j-nop
.jar, slf4j-simple
.jar, slf4j-log4j12
.jar, slf4j-jdk14
.jar or logback-classic
.jar
on the class path should prove to be an effective remedy
.
Detected both log4j-over-slf4j
.jar AND slf4j-reload4j
on the class path, preempting StackOverflowError
.
The purpose of slf4j-reload4j module is to delegate or redirect calls made to an SLF4J logger to log4j/reload4j
. The purpose of the log4j-over-slf4j module is to redirect calls made to a log4j logger to SLF4J
. If SLF4J is bound withslf4j-reload4j
.jar and log4j-over-slf4j
.jar is also present
on the class path, a StackOverflowError will inevitably occur immediately after the first invocati
on of an SLF4J or a log4j logger
.
Here is how the excepti
on might look like:
Excepti
on in thread "main"
java.lang
.StackOverflowError
at
java.util
.Hashtable
.c
ontainsKey(Hashtable
.java:30
6)
at org
.apache
.log4j
.Log4jLoggerFactory
.getLogger(Log4jLoggerFactory
.java:3
6)
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
...
Since 1
.5
.11 SLF4J software preempts the inevitable stack overflow error by throwing an excepti
on with details about the actual cause of the problem
. This is deemed to be better than leaving the user w
ondering about the reas
ons of the StackOverflowError
.
Note that since reload4j provides the log4j 1
.x API, reload4j
.jar and log4j-over-slf4j
.jar cannot be present simultaneously
on your classpath
.
For more background
on this topic see Bridging legacy APIs
.
Detected both jcl-over-slf4j
.jar AND slf4j-jcl
.jar
on the class path, preempting StackOverflowError
.
The purpose of slf4j-jcl module is to delegate or redirect calls made to an SLF4J logger to jakarta comm
ons 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 slf4j-jcl
.jar and jcl-over-slf4j
.jar is also present
on the class path, then a StackOverflowError will inevitably occur immediately after the first invocati
on of an SLF4J or a JCL logger
.
Here is how the excepti
on might look like:
Excepti
on 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
.comm
ons
.logging
.impl
.SLF4JLogFactory
.getInstance(SLF4JLogFactory
.java:155)
at org
.apache
.comm
ons
.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
.comm
ons
.logging
.impl
.SLF4JLogFactory
.getInstance(SLF4JLogFactory
.java:155)
subsequent lines omitted
...
Since 1
.5
.11 SLF4J software preempts the inevitable stack overflow error by throwing an excepti
on with details about the actual cause of the problem
. This is deemed to be better than leaving the user w
ondering about the reas
ons of the StackOverflowError
.
For more background
on this topic see Bridging legacy APIs
.
Excepti
on in thread "main"
java.lang
.NoSuchFieldError: tlm
Excepti
on in thread "main"
java.lang
.NoSuchFieldError: tlm
at org
.apache
.log4j
.MDCFriend
.fixFor
Java9(MDCFriend
.java:11)
at org
.slf4j
.impl
.Log4jMDCAdapter
.(Log4jMDCAdapter
.java:38)
at Main
.main(Main
.java:5)
The NoSuchFieldError is thrown when slf4j-log4j12 attempts to access the 'tlm' package private field in org
.apache
.log4j
.MDC which was specified as being of type
java.lang
.Object in log4j 1
.2
.x but was changed to
java.lang
.ThreadLocal in reload4j
. Moreover, such access to package private fields from different modules is not authorized by default in modularized applicati
ons in
Java 9 and later
.
To keep a l
ong story short, the NoSuchFieldError can be avoided by using slf4j-reload4j
.jar with reload4j
.jar
. Stated differently, org
.slf4j
.MDC cannot be used with the slf4j-log4j12
.jar and reload4j
.jar combinati
on.
Update: The issue described above was fixed in reload4j 1
.2
.21
. Although it is still recommended that you use slf4j-reload4j as the preferred adapter for the slf4j/reload4j combinati
on, with reload4j versi
on 1
.2
.21 and later you can freely mix any versi
on of slf4j-log4j12, if you need to
.
Failed to load class "org
.slf4j
.impl
.StaticMDCBinder"
This error indicates that appropriate SLF4J binding could not be found
on the class path
. Placing
one (and
only
one) of slf4j-nop
.jar, slf4j-simple
.jar, slf4j-log4j12
.jar, slf4j-jdk14
.jar or logback-classic
.jar
on the class path should solve the problem
.
MDCAdapter cannot be null
This error is reported when org
.slf4j
.MDC class has not been initialized correctly
. Same cause and remedy as the previously listed item
.
A number (N) of logging calls during the initializati
on phase have been intercepted and are now being replayed
. These are subject to the filtering rules of the underlying logging system
.
since 1
.7
.15 Logging calls made during the initializati
on phase are recorded and replayed post-initializati
on. Note that the replayed logging calls are subject to filtering by the underlying logging system
.
In principle, replaying
only occurs for applicati
ons which are already multithreaded at the time the first logging call occurs
.
See also substitute loggers
.
Substitute loggers were created during the default c
onfigurati
on phase of the underlying logging system
Highly c
onfigurable logging systems such as logback and log4j may create comp
onents which invoke loggers during their own initializati
on. See issue LOGBACK-127 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 h
onor such logger creati
on requests
.
To avoid this chicken-and-egg problem, SLF4J creates substitute loggers during this phase (initializati
on)
. Calls made to the substitute loggers during this phase are simply dropped
. After the initializati
on completes, the substitute logger will delegate logging calls to the appropriate logger implementati
on and otherwise will functi
on as any other logger returned by LoggerFactory
.
If any substitute logger had to be created, SLF4J will emit a listing of such loggers
. This list is intended to let you know that any logging calls made to these loggers during initializati
on have been dropped
.
See also intercepted and replayed logging calls
.
SLF4J versi
ons 1
.4
.0 and later requires log4j 1
.2
.12 or later
The trace level was added to log4j in versi
on 1
.2
.12 released
on August 29, 2005
. The trace level was added to the SLF4J API in versi
on 1
.4
.0
on May 1
6th, 2007
. Thus, starting with SLF4J 1
.4
.0, the log4j binding for SLF4J requires log4j versi
on 1
.2
.12 or above
.
However, as reported in issue 59, in some envir
onments it may be difficult to upgrade the log4j versi
on. To accommodate such circumstances, SLF4J's Log4jLoggerAdapter will map the TRACE level as DEBUG
.
java.lang
.NoClassDefFoundError: org/slf4j/event/LoggingEvent
Logback-classic versi
on 1
.1
.4 and later require slf4j-api versi
on 1
.7
.15 or later
.
With an earlier slf4j-api
.jar in the classpath, attempting introspecti
on of a Logger instance returned by logback versi
on 1
.1
.4 or later will result in a NoClassDefFoundError similar to that shown below
.
Excepti
on 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:12
61)
at
java.beans
.Introspector
.getTargetMethodInfo(Introspector
.java:1122)
at
java.beans
.Introspector
.getBeanInfo(Introspector
.java:414)
at
java.beans
.Introspector
.getBeanInfo(Introspector
.java:1
61)
Placing slf4j-api
.jar versi
on 1
.7
.15 or later in the classpath should solve the issue
.
Note that this problem
only occurs with logback versi
on 1
.1
.4 and later, other bindings such as slf4j-log4j, slf4j-jdk14 and slf4j-simple are unaffected
.
扫一扫
4499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
