Your feedback is requested on changes under consideration for SLF4J version 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 implementation
. 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-
operation (NOP) logger provider
.
Please note that slf4j-api version 2
.0
.x and later use
the ServiceLoader mechanism
. Earlier versions relied on
the static binder mechanism which is no longer honored by slf4j-api
. Please read
the FAQ entry What has changed in SLF4J version 2
.0
.0? for fur
ther important
details.
If you are responsible for packaging an application and do not care about logging,
then placing slf4j-nop
.jar on
the class path of your application will get rid of this warning message
. Note that em
bedded components 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 contains SLF4J bindings targeting slf4j-api versions 1
.7
.x or earlier
Planning for
the advent of Jigsaw (Java 9), slf4j-api version 2
.0
.x and later use
the ServiceLoader mechanism
. Earlier versions of SLF4J relied on
the static binder mechanism which is no longer honored by slf4j-api version 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 o
therwise will ignore
them
.
This can
be solved by placing an SLF4J provider on your classpath, such providers include logback version 1
.3
.x and later, as well as one of slf4j-reload4j, slf4j-jdk14, slf4j-simple version 2
.0
.0 or later
.
See also
the FAQ entry What has changed in SLF4J version 2
.0
.0? for fur
ther important
details.
IllegalStateException: org
.slf4j
.LoggerFactory in failed state
. Original exception was thrown EARLIER
.
This IllegalStateException is thrown post-initialization and informs
the user that initialization of LoggerFactory has failed
.
Note It is important to realize that
the exception causing
the failure was thrown at an earlier stage
. This earlier exception should provide more valuable information about
the root cause of
the problem
.
The method o
.a
.commons
.logging
.impl
.SLF4FLogFactory#release was invoked
.
Given
the structure of
the commons-logging API, in particular as implemented by SLF4J,
the o
.a
.commons
.logging
.impl
.SLF4FLogFactory#release() method should never
be called
. However, depending on
the deployment of commons-logging
.jar files in your servlet container, release() method may
be unexpectedly invoked by a copy of org
.apache
.commons
.logging
.LogFactory class shipping with commons-logging
.jar
.
This is a relatively common occurrence with recent versions of Tomcat, especially if you place jcl-over-slf4j
.jar in WEB-INF/lib directory of your web-application instead of $TOMCAT_HOME/common/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/common/lib without placing a copy in your web-applications
.
Please also
see bug #22
.
Operation [suchAndSuch] is not supported in jcl-over-slf4j
.
An Unsupported
OperationException is thrown whenever one of
the protected methods introduced in JCL 1
.1 are invoked
. These methods are invoked by LogFactory implementations shipping with commons-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 commons-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
.commons
.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 version 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 version 2
.0 or later but slf4j-api version 1
.7
.x or earlier
. Slf4j-api versions 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 version 1
.6, in
the absence of a binding, SLF4J will default to a no-
operation (NOP) logger implementation
.
If you are responsible for packaging an application and do not care about logging,
then placing slf4j-nop
.jar on
the class path of your application will get rid of this warning message
. Note that em
bedded components 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 location 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 o
ther 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-
operation) binding,
then remove slf4j-simple-2
.0
.17
.jar from
the class path
.
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, cassandra-all version 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 declaration 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>
<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>
Note
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
.
Em
bedded 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 em
bedded 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
.
slf4j-api version 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 versions 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 versions 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 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 slf4j-api
.jar, and as long as
the version of slf4j-api
.jar and its binding match, you should
be fine
.
At initialization time, if SLF4J suspects that
there may
be an api vs
. binding version mismatch problem, it will emit a warning about
the suspected mismatch
.
Logging factory implementation
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 invocation of an SLF4J or a log4j logger
.
Here is how
the exception might look like:
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
...
Since 1
.5
.11 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 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 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 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 invocation of an SLF4J or a JCL logger
.
Here is how
the exception might look like:
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
...
Since 1
.5
.11 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 StackOverflowError
.
For more background on this topic
see Bridging legacy APIs
.
Exception in thread "main" java
.lang
.NoSuchFieldError: tlm
Exception in thread "main" java
.lang
.NoSuchFieldError: tlm
at org
.apache
.log4j
.MDCFriend
.fixForJava9(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 applications in Java 9 and later
.
To keep a long 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 combination
.
Update:
The issue descri
bed 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 combination, with reload4j version 1
.2
.21 and later you can freely mix any version 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 num
ber (N) of logging calls during
the initialization 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 initialization phase are recorded and replayed post-initialization
. Note that
the replayed logging calls are subject to filtering by
the underlying logging system
.
In principle, replaying only occurs for applications which are already multithreaded at
the time
the first logging call occurs
.
See also substitute loggers
.
Substitute loggers were created during
the default configuration phase of
the underlying logging system
Highly configurable logging systems such as logback and log4j may create components which invoke loggers during
their own initialization
. 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 honor such logger creation requests
.
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 o
therwise will function as any o
ther 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 initialization have
been dropped
.
See also intercepted and replayed logging calls
.
SLF4J versions 1
.4
.0 and later requires log4j 1
.2
.12 or later
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
.
However, as reported in issue 59, in some environments it may
be difficult to upgrade
the log4j version
. To accommodate such circumstances, SLF4J's Log4jLoggerAdapter will map
the TRACE level as DEBUG
.
java
.lang
.NoClassDefFoundError: org/slf4j/event/LoggingEvent
Logback-classic version 1
.1
.4 and later require slf4j-api version 1
.7
.15 or later
.
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 NoClassDefFoundError similar to that shown
below
.
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
.get
BeanInfo(Introspector
.java:414)
at java
.beans
.Introspector
.get
BeanInfo(Introspector
.java:161)
Placing slf4j-api
.jar version 1
.7
.15 or later in
the classpath should solve
the issue
.
Note that this problem only occurs with logback version 1
.1
.4 and later, o
ther bindings such as slf4j-log4j, slf4j-jdk14 and slf4j-simple are unaffected
.
本文详细介绍了当尝试安装Android Native Development Tools时遇到错误提示'无法完成安装，因为一个或多个必需项未找到'的解决方案。通过两种方法解决资源未下载导致的安装失败问题：一种是复制并运行特定目录的android.bat文件；另一种是下载并替换tools目录中的文件。此外，还提供了重新运行SDKSetup.exe步骤来完成安装。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
扫一扫
4034
