java日誌組件的關係 slf4j logback log4j

 

 

 

 

 

轉自:http://www.blogjava.net/daiyongzhi/archive/2014/04/13/412364.htmlhtml

common-logging是apache提供的一個通用的日誌接口。用戶能夠自由選擇第三方的日誌組件做爲具體實現,像log4j,或者jdk自帶的logging, common-logging會經過動態查找的機制,在程序運行時自動找出真正使用的日誌庫。固然,common-logging內部有一個Simple logger的簡單實現,可是功能很弱。因此使用common-logging,一般都是配合着log4j來使用。使用它的好處就是,代碼依賴是 common-logging而非log4j, 避免了和具體的日誌方案直接耦合,在有必要時,能夠更改日誌實現的第三方庫。java

使用common-logging的常見代碼:
[java]  view plain copy
  1. import org.apache.commons.logging.Log;  
  2. import org.apache.commons.logging.LogFactory;  
  3.   
  4. public class A {  
  5.     private static Log logger = LogFactory.getLog(this.getClass());  
  6. }  
動態查找原理:Log 是一個接口聲明。LogFactory 的內部會去裝載具體的日誌系統,並得到實現該Log 接口的實現類。LogFactory 內部裝載日誌系統的流程以下:
  1. 首先,尋找org.apache.commons.logging.LogFactory 屬性配置。
  2. 不然,利用JDK1.3 開始提供的service 發現機制,會掃描classpah 下的META-INF/services/org.apache.commons.logging.LogFactory文件,若找到則裝載裏面的配置,使用裏面的配置。
  3. 不然,從Classpath 裏尋找commons-logging.properties ,找到則根據裏面的配置加載。
  4. 不然,使用默認的配置:若是能找到Log4j 則默認使用log4j 實現,若是沒有則使用JDK14Logger 實現,再沒有則使用commons-logging 內部提供的SimpleLog 實現。
從上述加載流程來看,只要引入了log4j.jar 並在classpath 配置了log4j.xml ,則commons-logging 就會使log4j 使用正常,而代碼裏不須要依賴任何log4j 的代碼。

slf4j

slf4j全 稱爲Simple Logging Facade for JAVA,java簡單日誌門面。相似於Apache Common-Logging,是對不一樣日誌框架提供的一個門面封裝(是接口而非實現),能夠在部署的時候不修改任何配置便可接入一種日誌實現方案。可是,他在編譯時靜態綁定真正的Log庫。使用SLF4J時,若是你須要使用某一種日誌實現,那麼你必須選擇正確的SLF4J的jar包的集合(各類橋接包)。apache

使用slf4j的常見代碼:
編程

[java]  view plain copy
  1. import org.slf4j.Logger;  
  2. import org.slf4j.LoggerFactory;  
  3.   
  4. public class A {  
  5.     private static Logger logger = LoggerFactory.getLogger(RdpMonitorService.class); 
  6. }  


slf4j靜態綁定原理SLF4J 會在編譯時會綁定import org.slf4j.impl.StaticLoggerBinder; 該類裏面實現對具體日誌方案的綁定接入。任何一種基於slf4j 的實現都要有一個這個類。如:org.slf4j.slf4j-log4j12-1.5.6: 提供對 log4j 的一種適配實現。
api

注意:若是有任意兩個實現slf4j 的包同時出現,那麼就可能出現問題。
框架

slf4j 與 common-logging 比較(都是日誌接口而非實現)

common-logging經過動態查找的機制, 在程序運行時自動找出真正使用的日誌庫。因爲它使用了ClassLoader尋找和載入底層的日誌庫, 致使了象OSGI這樣的框架沒法正常工做,由於OSGI的不一樣的插件使用本身的ClassLoader。 OSGI的這種機制保證了插件互相獨立,然而卻使Apache Common-Logging沒法工做。

slf4j編譯時靜態綁定真正的Log庫,所以能夠再OSGI中使用。另外,SLF4J 支持參數化的log字符串,避免了以前爲了減小字符串拼接的性能損耗而不得不寫的if(logger.isDebugEnable()),如今你能夠直接寫:logger.debug(「current user is: {}」, user)。拼裝消息被推遲到了它可以肯定是否是要顯示這條消息的時候,可是獲取參數的代價並無倖免。

Log4j

Apache 的一個開放源代碼項目,經過使用Log4j,咱們能夠控制日誌信息輸送的目的地是控制檯、文件、GUI組件、甚至是套接口服務 器、NT的事件記錄器、UNIX Syslog守護進程等;用戶也能夠控制每一條日誌的輸出格式;經過定義每一條日誌信息的級別,用戶可以更加細緻地控制日誌的生成過程。這些能夠經過一個 配置文件來靈活地進行配置,而不須要修改程序代碼。

LogBack

Logback 是由log4j創始人設計的又一個開源日記組件。logback當前分紅三個模塊:logback-core,logback- classic和logback-access。logback-core是其它兩個模塊的基礎模塊。logback-classic是log4j的一個改良版本。此外logback-classic完整實現SLF4J API使你能夠很方便地更換成其它日記系統如log4j或JDK14 Logging。logback-access訪問模塊與Servlet容器集成提供經過Http來訪問日記的功能。 

Log4j 與 LogBack 比較(都是日誌記錄器的實現)

LogBack 做爲一個通用可靠、快速靈活的日誌框架,將做爲Log4j的替代和SLF4J組成新的日誌系統的完整實現。LogBack聲稱具備極佳的性能,「 某些關鍵操做,好比斷定是否記錄一條日誌語句的操做,其性能獲得了顯著的提升。這個操做在LogBack中須要3納秒,而在Log4J中則須要30納秒。 LogBack建立記錄器(logger)的速度也更快:13微秒,而在Log4J中須要23微秒。更重要的是,它獲取已存在的記錄器只需94納秒,而 Log4J須要2234納秒,時間減小到了1/23。跟JUL相比的性能提升也是顯著的」。 另外,LOGBack的全部文檔是全面免費提供的,不象Log4J那樣只提供部分免費文檔而須要用戶去購買付費文檔。 
 

slf4j與其餘各類日誌組件的橋接

應用代碼中使用slf4j接口,接入具體實現的方法

應用代碼中使用別的日誌接口,轉成slf4j的方法


日誌組件相關歷史

Java 界裏有許多實現日誌功能的工具,最先獲得普遍使用的是 log4j,許多應用程序的日誌部分都交給了 log4j,不過做爲組件開發者,他們但願本身的組件沒關係緊依賴某一個工具,畢竟在同一個時候還有不少其餘不少日誌工具,假如一個應用程序用到了兩個組件,剛好兩個組件使用不一樣的日誌工具,那麼應用程序就會有兩份日誌輸出了。

爲了解決這個問題,Apache Commons Logging (以前叫 Jakarta Commons Logging,JCL)粉墨登場,JCL 只提供 log 接口,具體的實現則在運行時動態尋找。這樣一來組件開發者只須要針對 JCL 接口開發,而調用組件的應用程序則能夠在運行時搭配本身喜愛的日誌實踐工具。

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

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

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

Component
|
| log to Apache Commons Logging
V
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 裏。
轉自:http://www.blogjava.net/daiyongzhi/archive/2014/04/13/412363.html

幾乎在每一個jar包裏均可以看到log4j的身影,在多個子工程構成項目中,slf4j相關的衝突時不時就跳出來讓你不爽,那麼slf4j-api、slf4j-log4j12還有log4j他們是什麼關係?我把本身瞭解的和你們簡單分享一下:工具

    slf4j:Simple Logging Facade for Java,爲java提供的簡單日誌Facade。Facade:門面,更底層一點說就是接口。他容許用戶以本身的喜愛,在工程中經過slf4j接入不一樣 的日誌系統。更直觀一點,slf4j是個數據線,一端嵌入程序,另外一端連接日誌系統,從而實現將程序中的信息導入到日誌系統並記錄。 性能

   所以,slf4j入口就是衆多接口的集合,他不負責具體的日誌實現,只在編譯時負責尋找合適的日誌系統進行綁定。具體有哪些接口,所有都定義在slf4j-api中。查看slf4j-api源碼就能夠發現,裏面除了public final class LoggerFactory類以外,都是接口定義。所以,slf4j-api本質就是一個接口定義。this

      

下圖比較清晰的描述了他們之間的關係:url


   

     

 

  當系統採用log4j做爲日誌框架實現的調用關係:

    

    首先系統包含slf4j-api做爲日誌接入的接口;

    

    at compile時slf4j-api中public final class LoggerFactor類中

    private final static void bind() 方法會尋找具體的日誌實現類綁定,主要經過
    StaticLoggerBinder.getSingleton();語句調用

    

  

   slf4j-log4j12:連接slf4j-api和log4j中間的適配器。它實現了slf4j-apiz中StaticLoggerBinder接口,從而使得在編譯時綁定的是slf4j-log4j12的getSingleton()方法

log4j:這個是具體的日誌系統。經過slf4j-log4j12初始化Log4j,達到最終日誌的輸出。

 

 

 

 

============================================================================

本身的理解

1)apache common-logging 和 slf4j 都是日誌接口,而非實現,雖然他們可能自帶有一個極簡的實現;

2)log4j、logback、還有 log4j2 等都是日誌記錄器的實現;

3)日誌接口如何查找日誌實現類庫: common-logging 經過動態綁定,到classpath去尋找;

     slf4j 編譯時會靜態綁org.slf4j.impl.StaticLoggerBinder這個類,而其餘的日誌實現 log4j、logback 的實現中包括該類的實現,具體實現代碼就是綁定  本身的實現到 slf4j .

4)採用 slf4j 接口時,會涉及到 綁定器 和 橋接器 。slf4j-log4j12-version.jar 綁定 slf4j到log4j,jcl-over-slf4j 將採用jcl接口的日誌都橋接到slf4j接口,而後會採用slf4j的綁定器中綁定的日誌實現來記錄日誌。

5)使用 SLF4J 的比較典型搭配就是把 slf4j-api、JCL 橋接器、java.util.logging(JUL)橋接器、log4j 綁定器、log4j 這5個 jar 放置在 CLASS_PATH 裏。原理就是使用 slf4j 的各類橋接器,將全部日誌接口都橋接到 slf4j 這個接口,而後選擇一個具體的 slf4j 綁定器 和 日誌實現器,達到將全部日誌統一使用一個日誌實現器進行統一輸出的目的。

6)slf4j-api.jar 是slf4j自身的接口,common-logging.jar是接口,log4j.jar, logback.jar,log4j2.jar是實現;jcl-over-slf4j是jcl橋接到slf4j的jar包;slf4j-log4j.jar是slf4j綁定到log4j的jar包。

因此分爲:接口jar包、實現jar包、橋接到slf4j的jar包、slf4j綁定到實現的jar包接口到接口是經過橋接包,接口到實現是經過綁定包

7)最後給出兩個實例:

1> slf4j + log4j:

複製代碼
        <!-- slf4j interface--> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.6.1</version> </dependency> <!-- jcl bridge to slf4j --> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.6.1</version> </dependency> <!-- slf4j binding to log4j --> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.6.1</version> </dependency> <!-- log4j recorder --> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.17</version> </dependency>
複製代碼

2> slf4j + logback 最簡形式:

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

logback會自動引入 logback-core 和 slf4j:

3> slf4j + logback + jcl橋接:

複製代碼
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>1.1.3</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.6.1</version> </dependency>
複製代碼

看起來 logback 配置確實比log4j要簡單得多。

相關文章
相關標籤/搜索