log4j 和 commons-logging 在 2007 年相繼停止了更新，對於得到如此廣泛應用的框架來說，這是個讓人不安的事實。幸運的是，log4j 的作者 Ceki Gülcü 這幾年並沒有閒着，而是帶給了我們 slf4j 和 logback。儘管名字改變了，也不再有 Apache 的光環籠罩着，但任何一個使用過 log4j 的開發者對 slf4j 的 API 和 logback 的配置方式都不會感到陌生，甚至，你可能會認爲這就是新版本的 log4j 。
除了解決 commons-logging 被人詬病已久的 ClassLoader 問題，slf4j 和 logback 還做出了一些細節上的改進。對那些已經受夠了 commons-logging 和 log4j 的小毛病折磨的開發者來說，這些改進提供了相當充分的理由讓我們來考慮“升級”到 slf4j 和 logback 。
Parameterized Logging
這個是 slf4j 最討人喜歡的改進了，不必再爲了避免性能損失而到處做 if ( logger.isDebugEnabled() ) 這樣的檢查，也不必爲了插入幾個變量而把一句話拆成很多段來寫，在很大程度上挽救了開發者的審美情趣。
Default Logging Functionality
當無法找到配置文件時，log4j 只會輸出幾行錯誤信息，然後就直接罷工了，而 logback 則能夠優雅地切換到內置的缺省配置，輸出 Debug 或更高級別的 Log 到 Console 。對於應用程序的開發來說，log 的配置文件很可能不是從默認位置讀取的，因此 logback 的處理方式使得開發者更容易診斷應用程序初始化階段出現的問題。
Variable Substitution
雖然 log4j 也支持這個特性，但查找範圍僅限於 Java System Property，而 logback 則像很多其它框架一樣，支持載入外部 .properties 文件，所以開發應用程序的時候，可以把運行環境相關的配置集中在一個 .properties 文件中，提供給各個框架解析，不需要再單獨爲了 logging 進行設置。
slf4j 提供了豐富的 bridge module 與 commons-logging，log4j 和 java.util.logging 進行協作，遷移到 slf4j 的技術風險被降到了最低。最大的決定因素來自於對已有代碼進行修改的工作量，儘管 slf4j 提供了一個移植工具來幫助修改源代碼，但只能進行一些基本的 Class 替換，轉變到 Parameterized Logging 仍然必須通過手工修改源代碼。
採用 logback 要考慮的情況稍微複雜一些。目前只有 slf4j 支持 logback，但對於應用程序而言，仍然有大量的第三方的 lib 使用的是 commons-logging API， 爲此，slf4j 提供了山寨版的 jcl-over-slf4j.jar 在集成階段替換 commons-logging.jar （也有對應 log4j 和 java.util.logging 的山寨版），從而將所有的 Logging 都集中交給 slf4j 處理。如果應用程序使用了 Maven 進行依賴管理的話，由於第三方 lib 對於 commons-logging.jar 的依賴具有傳遞性，對其逐個添加 exclusion 顯然是很繁瑣的，用釜底抽薪的方法更簡單些，相應的零件可以在 JBoss Repository 中找到。最後，還得留意某些應用服務器的陷阱，例如 IBM Websphere Application Server 6.0 內置了 commons-logging 並且會將其暴露給部署的應用程序並且默認的 ClassLoader 策略是 Parent First……
轉載自：http://www.blogjava.net/parkerwy/archive/2009/10/25/299675.html