SLF4J warning or error messages and their meanings(转)
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 UnsupportedOperationException
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 theLoggerFactory.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 error is reported 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.
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.
You can download SLF4J bindings from the project download page.
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 other bindings. For example, if you have both slf4j-simple-1.7.10.jar and slf4j-nop-1.7.10.jar on the class path and you wish to use the nop (no-operation) binding, then remove slf4j-simple-1.7.10.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 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.
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.
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 mixing different versions of slf4j-api.jar and SLF4J binding can cause problems. For example, if you are using slf4j-api-1.7.10.jar, then you should also use slf4j-simple-1.7.10.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 a 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-log4j12.jar on the class path, preempting StackOverflowError
.
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 both slf4j-log4j12.jar and log4j-over-slf4j.jar are 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
.
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 both slf4j-jcl.jar and jcl-over-slf4j.jar are present on the class path, then aStackOverflowError
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.
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.
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 bug 68, in some environments it may be difficult to upgrade the log4j version. To accommodate such circumstances, SLF4J'sLog4jLoggerAdapter
will map the TRACE level as DEBUG.
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 issueLOGBACK-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 otherwise will function as any other logger returned by LoggerFactory
.
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.
http://www.slf4j.org/codes.html#multiple_bindings
SLF4J warning or error messages and their meanings(转)的更多相关文章
- SLF4J warning or error messages and their meanings
来自:http://www.slf4j.org/codes.html#StaticLoggerBinder The method o.a.commons.logging.impl.SLF4FLogFa ...
- DB2 Error Messages (Sorted by SQLCODE)
DB2 Error Messages (Sorted by SQLCODE) DB2 Error Messages (Sorted by SQLCODE) SQLCODE SQLSTATE Descr ...
- CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.
今天,在用icinga服务器端测试客户端脚本时,报如下错误: [root@mysql-server1 etc]# /usr/local/icinga/libexec/check_nrpe -H 192 ...
- Visual Studio 2005 移植 - WINVER,warning C4996, error LINK1104
Visual Studio 2005 移植 - WINVER,warning C4996, error LINK1104 一.WINVER Compile result: WINVER not d ...
- jQuery-validate error messages in Twitter ...
http://www.jefclaes.be/2012/11/jquery-validate-error-messages-in.html something satisfactory. In thi ...
- Citect:How do I translate Citect error messages?
http://www.opcsupport.com/link/portal/4164/4590/ArticleFolder/51/Citect To decode the error messag ...
- 四种常见的提示弹出框(success,warning,error,loading)原生JavaScript和jQuery分别实现
原文:四种常见的提示弹出框(success,warning,error,loading)原生JavaScript和jQuery分别实现 虽然说现在官方的自带插件已经有很多了,但是有时候往往不能满足我们 ...
- composer在update时提示file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO
在开发的时候,需要把依赖的服务更新到最新,然后 手动composer update一下,提示如下: failed) Update failed (The "e "https://a ...
- 使用PHPMailer 中的报错解决 "Connection failed. Error #2: stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:"
PHPMailer项目地址:https://github.com/PHPMailer/PHPMailer 项目中用到PHPMailer,使用过程中报错:"Connection failed. ...
随机推荐
- poj 3252
http://poj.org/problem?id=3252//自己搞了很长时间...现在刚刚有点明白.. 1 #include <iostream> using namespace st ...
- U-Boot在FL2440上移植(一)----修改系统时钟
<一>U-boot源码结构 图片来自韦东山的<嵌入式linux应用开发完全手册> U-boot下载地址:ftp://ftp.denx.de/pub/u-boot/ 交叉编译工具 ...
- 【Java】:多线程下载
import java.io.InputStream; import java.io.RandomAccessFile; import java.net.URL; import java.net.UR ...
- BZOJ 1614: [Usaco2007 Jan]Telephone Lines架设电话线
题目 1614: [Usaco2007 Jan]Telephone Lines架设电话线 Time Limit: 5 Sec Memory Limit: 64 MB Description Farm ...
- DescribingDesign Patterns 描述设计模式
DescribingDesign Patterns 描述设计模式 How do we describe design patterns?Graphical notations, while impor ...
- input file 在开发中遇到的问题 类似ajax form表单提交 input file中的文件
最近在做项目的过程中遇到个问题,在这里做个记录防止日后忘记 现今的主流浏览器由于ajax提交form表单无法把文件类型数据提交到后台,供后台处理,可是开发中由于某些原因又不得不用ajax提交文件, 为 ...
- Python之路Day7
第7天主要是面向对象的内容. 学到现在越来越吃力了,从上节课开始博客就没时间写了,看看别人写的博客都那么棒.又想起了那句话比你牛逼的人都在努力,你却在放羊...唉,我写作业的效率有点低,以后得抓紧时间 ...
- BFS 、DFS 解决迷宫入门问题
问题 B: 逃离迷宫二 时间限制: 1 Sec 内存限制: 128 MB提交: 12 解决: 5[提交][状态][讨论版] 题目描述 王子深爱着公主.但是一天,公主被妖怪抓走了,并且被关到了迷宫. ...
- 登陆整合实现-QQ互联认证(ASP.NET版本)
原文:登陆整合实现-QQ互联认证(ASP.NET版本) 首先 我们创建一个qq.ashx的页面,这个页面会跳转到QQ的请求界面 代码如下: QQSettingConfig qqSettingConfi ...
- JavaScript自调用匿名函数
Self-Invoking Anonymous Function,即自调用匿名函数.顾名思义,该函数没有名称,不同的是,该函数定义后立即被调用.该函数的作用是在应用中初始化或做一次性工作. 普通匿名函 ...