airline_core日誌依賴

時間 2019-11-29

原文原文鏈接

<dependency>
           <groupId>org.slf4j</groupId>
           <artifactId>slf4j-api</artifactId>
       </dependency>
       <dependency>
           <groupId>org.slf4j</groupId>
           <artifactId>jcl-over-slf4j</artifactId>
       </dependency>
       <dependency>
           <groupId>org.slf4j</groupId>
           <artifactId>log4j-over-slf4j</artifactId>
       </dependency>
       <dependency>
           <groupId>org.apache.logging.log4j</groupId>
           <artifactId>log4j-core</artifactId>
       </dependency>
       <dependency>
           <groupId>org.apache.logging.log4j</groupId>
           <artifactId>log4j-slf4j-impl</artifactId>
           <exclusions>
               <exclusion>
                   <groupId>log4j</groupId>
                   <artifactId>log4j</artifactId>
               </exclusion>
           </exclusions>
       </dependency>
       <dependency>
           <groupId>com.qianbao</groupId>
           <artifactId>qianbao-logMDC</artifactId>
           <version>0.0.2</version>
           <exclusions>
               <exclusion>
                   <groupId>org.springframework</groupId>
                   <artifactId>spring</artifactId>
               </exclusion>
               <exclusion>
                   <groupId>javax.servlet</groupId>
                   <artifactId>servlet-api</artifactId>
               </exclusion>
           </exclusions>
       </dependency>html

jcl-over-slf4jjava

java 界裏有許多實現日誌功能的工具，最先獲得普遍使用的是 log4j，許多應用程序的日誌部分都交給了 log4j，不過做爲組件開發者，他們但願本身的組件沒關係緊依賴某一個工具，畢竟在同一個時候還有不少其餘不少日誌工具，假如一個應用程序用到了兩個組件，剛好兩個組件使用不一樣的日誌工具，那麼應用程序就會有兩份日誌輸出了。爲了解決這個問題，Apache Commons Logging （以前叫 Jakarta Commons Logging，JCL）粉墨登場，JCL 只提供 log 接口，具體的實現則在運行時動態尋找。這樣一來組件開發者只須要針對 JCL 接口開發，而調用組件的應用程序則能夠在運行時搭配本身喜愛的日誌實踐工具。web

因此即便到如今你仍會看到不少程序應用 JCL + log4j 這種搭配，不過當程序規模愈來愈龐大時，JCL的動態綁定並非總能成功，具體緣由你們能夠 Google 一下，這裏就再也不贅述了。解決方法之一就是在程序部署時靜態綁定指定的日誌工具，這就是 SLF4J 產生的緣由。spring

跟 JCL 同樣，SLF4J 也是隻提供 log 接口，具體的實現是在打包應用程序時所放入的綁定器（名字爲 slf4j-XXX-version.jar）來決定，XXX 能夠是 log4j12, jdk14, jcl, nop 等，他們實現了跟具體日誌工具（好比 log4j）的綁定及代理工做。舉個例子：若是一個程序但願用 log4j 日誌工具，那麼程序只需針對 slf4j-api 接口編程，而後在打包時再放入 slf4j-log4j12-version.jar 和 log4j.jar 就能夠了。apache

如今還有一個問題，假如你正在開發應用程序所調用的組件當中已經使用了 JCL 的，還有一些組建可能直接調用了 java.util.logging，這時你須要一個橋接器（名字爲 XXX-over-slf4j.jar）把他們的日誌輸出重定向到 SLF4J，所謂的橋接器就是一個假的日誌實現工具，好比當你把 jcl-over-slf4j.jar 放到 CLASS_PATH 時，即便某個組件本來是經過 JCL 輸出日誌的，如今卻會被 jcl-over-slf4j 「騙到」SLF4J 裏，而後 SLF4J 又會根據綁定器把日誌交給具體的日誌實現工具。過程以下編程

Componentapi

|oracle

| log to Apache Commons Loggingapp

Vless

jcl-over-slf4j.jar --- (redirect) ---> SLF4j ---> slf4j-log4j12-version.jar ---> log4j.jar ---> 輸出日誌

看到上面的流程圖可能會發現一個有趣的問題，假如在 CLASS_PATH 裏同時放置 log4j-over-slf4j.jar 和 slf4j-log4j12-version.jar 會發生什麼狀況呢？沒錯，日誌會被踢來踢去，最終進入死循環。

因此使用 SLF4J 的比較典型搭配就是把 slf4j-api、JCL 橋接器、java.util.logging（JUL）橋接器、log4j 綁定器、log4j 這5個 jar 放置在 CLASS_PATH 裏。

不過並非全部APP容器都是使用 log4j 的，好比 Google AppEngine 它使用的是 java.util.logging（JUL），這時應用 SLF4J 的搭配就變成 slf4j-api、JCL橋接器、logj4橋接器、JUL綁定器這4個 jar 放置在 WEB-INF/lib 裏。

橋接

某些類型因爲自身的邏輯，它具備兩個或兩個以上的維度變化，橋接模式（Bridge）缺點：增長了設計複雜度。抽象類的修改影響到子類。

jcl-over-slf4j結構以下,代碼不多:

本身一個抽象維度，SLF4JLogFactory獲取Logger橋接指向另外一個抽象SLF4j裏的Logger。

下面是jcl-over-slf4j源碼依賴:

log4j-over-slf4j

log4j-over-slf4j與slf4j-log4j12共存stack overflow異常分析以下:

http://www.tuicool.com/articles/INveIf

http://www.slf4j.org/manual.html#swapping

====

SLF4J user manual

The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks, such as java.util.logging, logback and log4j. SLF4J allows the end-user to plug in the desired logging framework at deployment time. Note that SLF4J-enabling your library/application implies the addition of only a single mandatory dependency, namely slf4j-api-1.8.0-beta0.jar.

SINCE 1.6.0 If no binding is found on the class path, then SLF4J will default to a no-operation implementation.

SINCE 1.7.0 Printing methods in the Logger interface now offer variants accepting varargs instead of Object[]. This change implies that SLF4J requires JDK 1.5 or later. Under the hood the Java compiler transforms the varargs part in methods into Object[]. Thus, the Logger interface generated by the compiler is indistinguishable in 1.7.x from its 1.6.x counterpart. It follows that SLF4J version 1.7.x is totally 100% no-ifs-or-buts compatible with SLF4J version 1.6.x.

SINCE 1.7.5 Significant improvement in logger retrieval times. Given the extent of the improvement, users are highly encouraged to migrate to SLF4J 1.7.5 or later.

SINCE 1.7.9 By setting the slf4j.detectLoggerNameMismatch system property to true, SLF4J can automatically spot incorrectly named loggers.

Hello World

As customary in programming tradition, here is an example illustrating the simplest way to output "Hello world" using SLF4J. It begins by getting a logger with the name "HelloWorld". This logger is in turn used to log the message "Hello World".

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld {
  public static void main(String[] args) {
    Logger logger = LoggerFactory.getLogger(HelloWorld.class);
    logger.info("Hello World");
  }
}

To run this example, you first need to download the slf4j distribution, and then to unpack it. Once that is done, add the file slf4j-api-1.8.0-beta0.jar to your class path.

Compiling and running HelloWorld will result in the following output being printed on the console.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

This warning is printed because no slf4j binding could be found on your class path.

The warning will disappear as soon as you add a binding to your class path. Assuming you add slf4j-simple-1.8.0-beta0.jar so that your class path contains:

slf4j-api-1.8.0-beta0.jar
slf4j-simple-1.8.0-beta0.jar

Compiling and running HelloWorld will now result in the following output on the console.

0 [main] INFO HelloWorld - Hello World

Typical usage pattern

The sample code below illustrates the typical usage pattern for SLF4J. Note the use of {}-placeholders on line 15. See the question "What is the fastest way of logging?" in the FAQ for more details.

1: import org.slf4j.Logger;
 2: import org.slf4j.LoggerFactory;
 3: 
 4: public class Wombat {
 5:  
 6:   final Logger logger = LoggerFactory.getLogger(Wombat.class);
 7:   Integer t;
 8:   Integer oldT;
 9:
10:   public void setTemperature(Integer temperature) {
11:    
12:     oldT = t;        
13:     t = temperature;
14:
15:     logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
16:
17:     if(temperature.intValue() > 50) {
18:       logger.info("Temperature has risen above 50 degrees.");
19:     }
20:   }
21: }

Binding with a logging framework at deployment time

As mentioned previously, SLF4J supports various logging frameworks. The SLF4J distribution ships with several jar files referred to as "SLF4J bindings", with each binding corresponding to a supported framework.

slf4j-log4j12-1.8.0-beta0.jar

Binding for log4j version 1.2, a widely used logging framework. You also need to place log4j.jar on your class path.

slf4j-jdk14-1.8.0-beta0.jar

Binding for java.util.logging, also referred to as JDK 1.4 logging

slf4j-nop-1.8.0-beta0.jar

Binding for NOP, silently discarding all logging.

slf4j-simple-1.8.0-beta0.jar

Binding for Simple implementation, which outputs all events to System.err. Only messages of level INFO and higher are printed. This binding may be useful in the context of small applications.

slf4j-jcl-1.8.0-beta0.jar

Binding for Jakarta Commons Logging. This binding will delegate all SLF4J logging to JCL.

logback-classic-1.0.13.jar (requires logback-core-1.0.13.jar)

NATIVE IMPLEMENTATION There are also SLF4J bindings external to the SLF4J project, e.g. logbackwhich implements SLF4J natively. Logback's ch.qos.logback.classic.Logger class is a direct implementation of SLF4J's org.slf4j.Logger interface. Thus, using SLF4J in conjunction with logback involves strictly zero memory and computational overhead.

To switch logging frameworks, just replace slf4j bindings on your class path. For example, to switch from java.util.logging to log4j, just replace slf4j-jdk14-1.8.0-beta0.jar with slf4j-log4j12-1.8.0-beta0.jar.

SLF4J does not rely on any special class loader machinery. In fact, each SLF4J binding is hardwired at compile time to use one and only one specific logging framework. For example, the slf4j-log4j12-1.8.0-beta0.jar binding is bound at compile time to use log4j. In your code, in addition to slf4j-api-1.8.0-beta0.jar, you simply drop one and only one binding of your choice onto the appropriate class path location. Do not place more than one binding on your class path. Here is a graphical illustration of the general idea.

The SLF4J interfaces and their various adapters are extremely simple. Most developers familiar with the Java language should be able to read and fully understand the code in less than one hour. No knowledge of class loaders is necessary as SLF4J does not make use nor does it directly access any class loaders. As a consequence, SLF4J suffers from none of the class loader problems or memory leaks observed with Jakarta Commons Logging (JCL).

Given the simplicity of the SLF4J interfaces and its deployment model, developers of new logging frameworks should find it very easy to write SLF4J bindings.

Libraries

Authors of widely-distributed components and libraries may code against the SLF4J interface in order to avoid imposing an logging framework on their end-user. Thus, the end-user may choose the desired logging framework at deployment time by inserting the corresponding slf4j binding on the classpath, which may be changed later by replacing an existing binding with another on the class path and restarting the application. This approach has proven to be simple and very robust.

As of SLF4J version 1.6.0, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of throwing a NoClassDefFoundError because the org.slf4j.impl.StaticLoggerBinder class is missing, SLF4J version 1.6.0 and later will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. For example, let Wombat be some biology-related framework depending on SLF4J for logging. In order to avoid imposing a logging framework on the end-user, Wombat's distribution includes slf4j-api.jar but no binding. Even in the absence of any SLF4J binding on the class path, Wombat's distribution will still work out-of-the-box, and without requiring the end-user to download a binding from SLF4J's web-site. Only when the end-user decides to enable logging will she need to install the SLF4J binding corresponding to the logging framework chosen by her.

BASIC RULE 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 transitive dependency on a specific binding, that binding is imposed on the end-user negating the purpose of SLF4J. Note that declaring a non-transitive dependency on a binding, for example for testing, does not affect the end-user.

SLF4J usage in embedded components is also discussed in the FAQ in relation with logging configuration, dependency reduction and testing.

Declaring project dependencies for logging

Given Maven's transitive dependency rules, for "regular" projects (not libraries or frameworks) declaring logging dependencies can be accomplished with a single dependency declaration.

LOGBACK-CLASSIC If you wish to use logback-classic as the underlying logging framework, all you need to do is to declare "ch.qos.logback:logback-classic" as a dependency in your pom.xml file as shown below. In addition to logback-classic-1.0.13.jar, this will pull slf4j-api-1.8.0-beta0.jar as well as logback-core-1.0.13.jar into your project. Note that explicitly declaring a dependency on logback-core-1.0.13 or slf4j-api-1.8.0-beta0.jar is not wrong and may be necessary to impose the correct version of said artifacts by virtue of Maven's "nearest definition" dependency mediation rule.

<dependency> 
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <version>1.0.13</version>
</dependency>

LOG4J If you wish to use log4j as the underlying logging framework, all you need to do is to declare "org.slf4j:slf4j-log4j12" as a dependency in your pom.xml file as shown below. In addition to slf4j-log4j12-1.8.0-beta0.jar, this will pull slf4j-api-1.8.0-beta0.jar as well as log4j-1.2.17.jar into your project. Note that explicitly declaring a dependency on log4j-1.2.17.jar or slf4j-api-1.8.0-beta0.jar is not wrong and may be necessary to impose the correct version of said artifacts by virtue of Maven's "nearest definition" dependency mediation rule.

<dependency> 
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>1.8.0-beta0</version>
</dependency>

JAVA.UTIL.LOGGING If you wish to use java.util.logging as the underlying logging framework, all you need to do is to declare "org.slf4j:slf4j-jdk14" as a dependency in your pom.xml file as shown below. In addition to slf4j-jdk14-1.8.0-beta0.jar, this will pull slf4j-api-1.8.0-beta0.jar into your project. Note that explicitly declaring a dependency on slf4j-api-1.8.0-beta0.jar is not wrong and may be necessary to impose the correct version of said artifact by virtue of Maven's "nearest definition" dependency mediation rule.

<dependency> 
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-jdk14</artifactId>
  <version>1.8.0-beta0</version>
</dependency>

Binary compatibility

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.

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.

Mixing different versions of slf4j-api.jar and SLF4J binding can cause problems. For example, if you are using slf4j-api-1.8.0-beta0.jar, then you should also use slf4j-simple-1.8.0-beta0.jar, using slf4j-simple-1.5.5.jar will not work.

However, from the client's perspective all versions of slf4j-api are compatible. Client code compiled with slf4j-api-N.jarwill 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.jarand its binding match, you should be fine.

At initialization time, if SLF4J suspects that there may be an slf4j-api vs. binding version mismatch problem, it will emit a warning about the suspected mismatch.

Consolidate logging via SLF4J

Often times, a given project will depend on various components which rely on logging APIs other than SLF4J. It is common to find projects depending on a combination of JCL, java.util.logging, log4j and SLF4J. It then becomes desirable to consolidate logging through a single channel. SLF4J caters for this common use-case by providing bridging modules for JCL, java.util.logging and log4j. For more details, please refer to the page on Bridging legacy APIs.

Mapped Diagnostic Context (MDC) support

"Mapped Diagnostic Context" is essentially a map maintained by the logging framework where the application code provides key-value pairs which can then be inserted by the logging framework in log messages. MDC data can also be highly helpful in filtering messages or triggering certain actions.

SLF4J supports MDC, or mapped diagnostic context. If the underlying logging framework offers MDC functionality, then SLF4J will delegate to the underlying framework's MDC. Note that at this time, only log4j and logback offer MDC functionality. If the underlying framework does not offer MDC, for example java.util.logging, then SLF4J will still store MDC data but the information therein will need to be retrieved by custom user code.

Thus, as a SLF4J user, you can take advantage of MDC information in the presence of log4j or logback, but without forcing these logging frameworks upon your users as dependencies.

For more information on MDC please see the chapter on MDC in the logback manual.

Executive summary

Advantage	Description
Select your logging framework at deployment time	The desired logging framework can be plugged in at deployment time by inserting the appropriate jar file (binding) on your class path.
Fail-fast operation	Due to the way that classes are loaded by the JVM, the framework binding will be verified automatically very early on. If SLF4J cannot find a binding on the class path it will emit a single warning message and default to no-operation implementation.
Bindings for popular logging frameworks	SLF4J supports popular logging frameworks, namely log4j, java.util.logging, Simple logging and NOP. The logback project supports SLF4J natively.
Bridging legacy logging APIs	The implementation of JCL over SLF4J, i.e jcl-over-slf4j.jar, will allow your project to migrate to SLF4J piecemeal, without breaking compatibility with existing software using JCL. Similarly, log4j-over-slf4j.jar and jul-to-slf4j modules will allow you to redirect log4j and respectively java.util.logging calls to SLF4J. See the page on Bridging legacy APIs for more details.
Migrate your source code	The slf4j-migrator utility can help you migrate your source to use SLF4J.
Support for parameterized log messages	All SLF4J bindings support parameterized log messages with significantly improved performance results.

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。