原文地址

通常，有些元件取決或依賴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

SLF4J上的JCL實現允許你逐漸遷移到SLF4J，特別是如果一些軟體依賴包在可見的將來繼續使用JCL.你可以立即享受SLF4J可靠性的益處，同時也保持向後相容性。只需將common-logging.jar替換為jcl-over-slf4j.jar。隨後，底層日誌框架的選擇將由SLF4J完成而不是JCL,但 [沒有折磨JCL類載入的頭疼]。底層日誌框架可以是任何SLF4J支援的框架。通常，用jcl-over-slf4j代替common-logging.jar

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是合適的：

1.  幾乎沒有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，導致一個死迴圈。