為什么要用日志（Log）?
這個……就不必說了吧。
為什么不用System.out.println()?
功能太弱；不易于控制。如果暫時不想輸出了怎么辦？如果想輸出到文件怎么辦？如果想部分輸出怎么辦？……
為什么同時使用commons-logging和Log4j?為什么不僅使用其中之一？
Commons-loggin的目的是為“所有的Java日志實現”提供一個統一的接口，它自身的日志功能平常弱（只有一個簡單的SimpleLog?），所以一般不會單獨使用它。
Log4j的功能非常全面強大，是目前的首選。我發現幾乎所有的Java開源項目都會用到Log4j，但我同時發現，所有用到Log4j的項目一般也同時會用到commons-loggin。我想，大家都不希望自己的項目與Log4j綁定的太緊密吧。另外一個我能想到的“同時使用commons-logging和Log4j”的原因是，簡化使用和配置。
強調一點，“同時使用commons-logging和Log4j”，與“單獨使用Log4j”相比，并不會帶來更大的學習、配置和維護成本，反而更加簡化了我們的工作。我想這也是為什么“所有用到Log4j的項目一般也同時會用到commons-loggin”的原因之一吧。
Commons-logging能幫我們做什么？
l 提供一個統一的日志接口，簡單了操作，同時避免項目與某個日志實現系統緊密a耦合
l 很貼心的幫我們自動選擇適當的日志實現系統（這一點非常好?。?/SPAN>
l 它甚至不需要配置
這里看一下它怎么“‘很貼心的’幫我們‘自動選擇’‘適當的’日志實現系統”：
1) 首先在classpath下尋找自己的配置文件commons-logging.properties，如果找到，則使用其中定義的Log實現類；
2) 如果找不到commons-logging.properties文件，則在查找是否已定義系統環境變量org.apache.commons.logging.Log，找到則使用其定義的Log實現類；
3) 否則，查看classpath中是否有Log4j的包，如果發現，則自動使用Log4j作為日志實現類；
4) 否則，使用JDK自身的日志實現類（JDK1.4以后才有日志實現類）；
5) 否則，使用commons-logging自己提供的一個簡單的日志實現類SimpleLog；
（以上順序不保證完全準確，請參考官方文檔）
可見，commons-logging總是能找到一個日志實現類，并且盡可能找到一個“最合適”的日志實現類。我說它“很貼心”實際上是因為：1、可以不需要配置文件；2、自動判斷有沒有Log4j包，有則自動使用之；3、最悲觀的情況下也總能保證提供一個日志實現（SimpleLog）。
可以看到，commons-logging對編程者和Log4j都非常友好。
為了簡化配置commons-logging，一般不使用commons-logging的配置文件，也不設置與commons-logging相關的系統環境變量，而只需將Log4j的Jar包放置到classpash中就可以了。這樣就很簡單地完成了commons-logging與Log4j的融合。如果不想用Log4j了怎么辦？只需將classpath中的Log4j的Jar包刪除即可。
就這么簡單！
代碼應該怎么寫？
我們在需要輸出日志信息的“每一人”類中做如下的三個工作：
1、導入所有需的commongs-logging類：
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
如果愿意簡化的話，還可以兩行合為一行：
import org.apache.commons.logging.*;
2、在自己的類中定義一個org.apache.commons.logging.Log類的私有靜態類成員：
private static Log log = LogFactory.getLog(YouClassName.class);
注意這里定義的是static成員，以避免產生多個實例。
LogFactory.getLog()方法的參數使用的是當前類的class，這是目前被普通認為的最好的方式。為什么不寫作LogFactory.getLog(this.getClass())？因為static類成員訪問不到this指針！
3、使用org.apache.commons.logging.Log類的成員方法輸出日志信息：
log.debug("111");
log.info("222");
log.warn("333");
log.error("444");
log.fatal("555");
這里的log，就是上面第二步中定義的類成員變量，其類型是org.apache.commons.logging.Log，通過該類的成員方法，我們就可以將不同性質的日志信息輸出到目的地（目的地是哪里？視配置可定，可能是stdout，也可能是文件，還可能是發送到郵件，甚至發送短信到手機……詳見下文對log4j.properties的介紹）：
l debug() 輸出“調試”級別的日志信息；
l info() 輸出“信息”級別的日志信息；
l warn() 輸出“警告”級別的日志信息；
l error() 輸出“錯誤”級別的日志信息；
l fatal() 輸出“致命錯誤”級別的日志信息；
根據不同的性質，日志信息通常被分成不同的級別，從低到高依次是：“調試（DEBUG）”“信息（INFO）”“警告（WARN）”“錯誤（ERROR）”“致命錯誤（FATAL）”。為什么要把日志信息分成不同的級別呢？這實際上是方便我們更好的控制它。比如，通過Log4j的配置文件，我們可以設置“輸出‘調試’及以上級別的日志信息”（即“調試”“信息”“警告”“錯誤”“致命錯誤”），這對項目開發人員可能是有用的；我們還可以設置“輸出“警告”及以上級別的日志信息”（即“警告”“錯誤”“致命錯誤”），這對項目最終用戶可能是有用的。
僅從字面上理解，也可以大致得出結論：最常用的應該是debug()和info()；而warn()、error()、fatal()僅在相應事件發生后才使用。
從上面三個步驟可以看出，使用commons-logging的日志接口非常的簡單，不需要記憶太多東西：僅僅用到了兩個類Log, LogFactory，并且兩個類的方法都非常少（后者只用到一個方法，前者經常用到的也只是上面第三步中列出的幾個），同時參數又非常簡單。
上面所介紹的方法是目前被普通應用的，可以說是被標準化了的方法，幾乎所有的人都是這么用。如果不信，或想確認一下，就去下載幾個知名的Java開源項目源代碼看一下吧。
下面給出一個完整的Java類的代碼：
package liigo.testlog;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class TestLog
{
private static Log log = LogFactory.getLog(TestLog.class);
public void test()
{
log.debug("111");
log.info("222");
log.warn("333");
log.error("444");
log.fatal("555");
}
public static void main(String[] args)
{
TestLog testLog = new TestLog();
testLog.test();
}
}
只要保證commons-logging的jar包在classpath中，上述代碼肯定可以很順利的編譯通過。那它的執行結果是怎么樣的呢？恐怕會有很大的不同，請繼續往下看。
Log4j在哪里呢？它發揮作用了嗎？
應該注意到，我們上面給出的源代碼，完全沒有涉及到Log4j——這正是我們所希望的，這也正是commons-logging所要達到的目標之一。
可是，怎么才能讓Log4j發揮它的作用呢？答案很簡單，只需滿足“classpath中有Log4j的jar包”。前面已經說過了，commons-logging會自動發現并應用Log4j。所以只要它存在，它就發揮作用。（它不存在呢？自然就不發揮作用，commons-logging會另行選擇其它的日志實現類。）
注意：配置文件log4j.properties對Log4j來說是必須的。如果classpath中沒有該配置文件，或者配置不對，將會引發運行時異常。
這樣，要正確地應用Log4j輸出日志信息，log4j.properties的作用就很重要了。好在該文件有通用的模板，復制一份（稍加修改）就可以使用。幾乎每一個Java項目目錄內都會有一個log4j.properties文件，可下載幾個Java開源項目源代碼查看。本文最后也附一個模板性質的log4j.properties文件，直接復制過去就可以用，或者根據自己的需要稍加修改。后文將會log4j.properties文件適當作一些介紹。