SLF4J Error Codes()

  本篇文章为你整理了SLF4J Error Codes()的详细内容,包含有 SLF4J Error Codes,希望能帮助你了解 SLF4J Error Codes。

   This warning, i.e. not an error, message is reported when

   no SLF4J providers could be found on the class path. Placing one

   (and only one) of slf4j-nop.jar

   slf4j-simple.jar, slf4j-reload4j.jar,

   slf4j-jdk14.jar or logback-classic.jar on the

   class path should solve the problem. Note that these providers

   must target slf4j-api 2.0.x or later.

   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 further 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 embedded 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 SLF4Js purpose.

  
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 finds no providers targeting SLF4J 2.0.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 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 further important details.

  
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.

  
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.

  
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.

  
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.

  
This warning message 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.

   Note that 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 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 SLF4Js purpose.

  
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-2.0.6.jar and

   slf4j-nop-2.0.6.jar on the class path and you wish

   to use the nop (no-operation) binding, then remove

   slf4j-simple-2.0.6.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 projects 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.

   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.

  
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.6.jar, then

   you should also use slf4j-simple-2.0.6.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.

  
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.

  
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.

  
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

   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 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 combination, with reload4j version 1.2.21

   and later you can freely mix any version of slf4j-log4j12, if you

   need to.

  
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.

  
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 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.

  
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

   otherwise will function 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 initialization

   have been dropped.

   See also intercepted and replayed logging calls.

  
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, SLF4Js

   Log4jLoggerAdapter will map the TRACE level as

   DEBUG.

  
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.getBeanInfo(Introspector.java:414)

   at java.beans.Introspector.getBeanInfo(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, other bindings such as slf4j-log4j, slf4j-jdk14 and

   slf4j-simple are unaffected.

  以上就是SLF4J Error Codes()的详细内容,想要了解更多 SLF4J Error Codes的内容,请持续关注盛行IT软件开发工作室。

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: