424
《SLF4J官方文檔》傳統橋接API
通常，有些組件取決或依賴Logging API，而不是SLF4J。你也可以假設不久的將來這些組件不會轉變成SLF4J。為了處理這種情況，SLF4J裝載了幾個可以重定向調用的橋接模塊，這些模塊使得log4j, JCL and java.util.logging APIs
表現得仿佛他們是SLF4J的代替。下圖闡述了這個想法。
請注意在你控製下的源代碼，你真得應該用slf4j-migrator。本頁所描述的基於二進製的解決方案是適合超出你控製範圍的軟件。
從Jakarta Commons Logging(JCL)逐漸遷移到SLF4J
jcl-over-slf4j.jar
為了簡易從JCL到SLF4J的遷移，SLF4J分步包含了jar文件jcl-over-slf4j.jar。這個jar文件是用來替代JCL1.1.1版本的。它實現了JCL的公共API，但它用的是SLF4J的底層，因此命名為“SLF4J上的JCL”.
SLF4J上的JCL實現允許你逐漸遷移到SLF4J，特別是如果一些軟件依賴包在可見的將來繼續使用JCL.你可以立即享受SLF4J可靠性的益處，同時也保持向後兼容性。隻需將common-logging.jar替換為jcl-over-slf4j.jar。隨後，底層日誌框架的選擇將由SLF4J完成而不是JCL,但 [沒有折磨JCL類加載的頭疼]。底層日誌框架可以是任何SLF4J支持的框架。通常，用jcl-over-slf4j代替common-logging.jar將立即地、永久地解決commons日誌相關的類加載問題。
Slf4j-jcl.jar
部分我們的用戶在轉換到SLF4J API後意識到在一些環境下，使用JCL是強製的，使用SLF4J可能成為問題。在這種不常見但很重要的情況下，SLF4J提供一個JCL綁定，在slf4j-jcl.jar中可以找到。JCL綁定將所有的由SLF4J產生的日誌調用分發給JCL。這樣，如果由於某些原因一個已存在的應用必須使用JCL,應用的部分仍可以用透明的方式編碼到大的應用環境，而不是SLF4J API。你選擇的SLF4J API將在應用的其餘部分不可見，這樣你可以繼續使用JCL.
jcl-over-slf4j.jar不能和 slf4j-jcl.jar混淆
SLF4J上的JCL, 也就是jcl-over-slf4j.jar，在JCL需要支持向後兼容的原因下，它派上了用場。與JCL聯係，它可以解決這些問題，沒有一定要采取SLF4J API，推遲到一段時間後再作決定。
另一方麵，在你的組件已經采用了SLF4J API後，slf4j-jcl.jar是有用的，你需要把組件嵌入到更大的應用環境中，在這個環境下JCL表麵上是需要的。在沒有擾亂應用的更大部分，你的軟件組件仍可以使用。實際上，slf4j-jcl.jar將分發所有的日誌決定給JCL,那樣組件依賴的SLF4J API將對更大的整體透明。
注意jcl-over-slf4j.jar和slf4j-jcl.jar不能同時部署。前一個jar文件將導致JCL分發日誌係統的選擇命令給SLF4J，後一個jar文件將導致SLF4J分發日誌係統的選擇命令給JCL。將導致無限循環 。
log4j-over-slf4j（slf4j上的log4j）
SLF4J裝載了一個叫log4j-over-slf4j的模塊。它允許log4j用戶轉移已存在的應用到SLF4J，同時不用改變一行代碼，隻需要簡單地用log4j-over-slf4j.jar代替log4j.jar。
它如何工作？
log4j-over-slf4j模塊包含了大部分使用的log4j類的替代類，是org.apache.log4j.Category, org.apache.log4j.Logger, org.apache.log4j.Priority,org.apache.log4j.Level, org.apache.log4j.MDC, and org.apache.log4j.BasicConfigurator.這些被替代類重新把所有的工作指向相關的SLF4J類。
在你自己的應用中使用log4j-over-slf4j，第一部是定位，然後用log4j-over-slf4j.jar代替log4j.jar。注意你仍需要SLF4J綁定，它是log4j-over-slf4j.jar完全工作的根基。
在大部分情況下，為了從log4j遷移到SLF4J，所有的花費隻是替換jar文件。
注意由於這個遷移，log4j配置文件將不再被獲得。如果你需要遷移log4j.properties文件到logback，log4j轉換器會給幫助。配置logback，請參考它的手冊 。
何時工作？
當應用調用不存在於橋接中log4j組件時，log4j-over-slf4j模塊將不會工作。比如，當應用代碼直接引用log4j輸出端，過濾器或者屬性配置器，log4j-over0slf4j將不會完全替代log4j。然而，當log4j通過配置文件配置後，變成log4j.properties 或 log4j.xml，log4j-over-slf4j模塊應該隻是工作良好。
係統開銷怎麼樣？
直接使用log4j-over-slf4j代替log4j的係統開銷相對小很多。之前已經給出，log4j-over-slf4j立即分配所有的工作給SLF4J, CPU的係統開銷在幾納秒內應該忽略不計。有個內存係統開銷，對應於每個日誌器的hashmap的入口，這個對於有幾千個日誌器的大應用來說是可以接受的。另外，如果你選擇logback作為底層日誌係統，已知logback比log4j更快同時更節省內存，使用logback直接代替log4j的增益應該補償了使用log4j-over-slf4j的過度花費。
log4j-over-slf4j.jar 和slf4j-log4j12.jar二者不能同時存在
slf4j-log4j12.jar是給SLF4J提供log4j綁定，這將迫使所有的SLF4J的調用分配給log4j。log4j-over-slf4j.jar將反過來講所有的log4J API調用分配給SLF4J等效的方法。如果二者同時存在，SLF4J調用將分發給log4j, 同時log4j調用重定向到SLF4J，導致進入一個死循環 。
jul-to-slf4j bridge（jul到slf4j橋接）
jul-to-slf4j模塊包括java.util.logging(jul)handler.叫做SLF4JBridgeHandler，它將所有接收到的jul記錄發送到SLF4J API。請看SLF4JBridgeHandler javadocs使用指導。
注意性能–與其他橋接模塊相反的名稱為jcl-over-slf4j和log4j-over-slf4j，二者重實現了JCL和獨立地log4j，jul-to-slf4j模塊沒有重實現java.util.logging，因為java.*下的包命名空間不能替換。反而，jul-to-slf4j等價地轉換LogRecord 對象到它們的SLF4J中。請注意轉換工程導致的構建LogRecord實例的花費，而不是SLF4J日誌器對於給定的等級是否已禁用了。因此，jul-to-slf4j轉換可能嚴重地增加了禁用日誌聲明的係統開銷（60倍或6000%），同時明顯地影響開啟日誌聲明的性能（大體上增加20%）。在LevelChangePropagator的幫助下，logback0.9.25版本可能完全消除禁用日誌聲明引起的60倍轉換係統開銷。
如果你關心應用的性能，隻有當下列2種情況是真的時，是用SLF4JBridgeHandler是合適的：
- 幾乎沒有u.l日誌聲明在運行
2．已安裝LevelChangePropagator
jul-to-slf4j.jar 和slf4j-jdk14.jar 二者不能同時存在
slf4j-jdk14.jar是jul到SLF4J的綁定，將強製SLF4J的調用分配給jul。另一方麵，jul-to-slf4j.jar，加上SLF4JBridgeHandler的安裝，加上SLF4JBridgeHandler的安裝,通過調用“SLF4JBridgeHandler.install()“將jul記錄發送給SLF4J。因此，如果兩個jar文件同時存在（SLF4JBridgeHandler已安裝），slf4的調用將被分配給jul, jul記錄將發送到SLF4J，導致一個死循環。
最後更新：2017-05-19 16:38:09