最近一直忙於做一個純技術驅動的項目：網店重生！就是要把網店版改造成爲基於Mysql的分佈式應用；由於在過去的1年半的時間裏面，網店版都沒有怎麼發展，只是一些例行維護；此次要這麼大規模重構的確是一個不小的挑戰，那在這個重構過程中，我們也再次遇到了當初的一些老問題，但由於以前的主力開發人員早已經不在一個團隊裏面了，所以很多的小問題還是讓我們費了一些力氣，趁此機會將這個過程中遇到的一些小問題記錄下來；
由於不被髮展，所以以前的很多測試環境都已經被用作其他用途了，而且目前用的Jboss主要版本與當初是不一致的；本篇要討論的是關於Jboss和Log4j的日誌衝突問題；其一就是要解決應用啓動過程中的這兩個異常，其二就是要搞清楚爲什麼會出現這2個異常，以及在解決問題過程中使用到的幾個關鍵配置項；
首先我們來看下我們經常會遇到的兩類異常信息，如下所示：
異常1：
異常2：
要想解決以上2個異常方法很簡單，修改Jboss的3個配置項即可，主要是針對於Jboss 4.*系列，對於之前的版本一般來說只會出現異常1的情況，此時只需要設置CatchSystemOut爲false即可；配置項如下：
JBOSS_HOME/server/default/conf/jboss-service.xml
JBOSS_HOME/server/default/jbossweb*.sar/META-INFO/jboss-service.xml
或者在web應用下的jboss-web.xml
下面我們來分析下以上涉及的3個配置項到底都是什麼意思：
- CatchSystemOut：他是Log4jService中的一個屬性，默認情況下沒有顯示配置該屬性，也即屬性值爲true；
因爲Jboss應用服務器自身也用Log4j來作爲日誌框架，而我們部署的應用中一般也會用Log4j來進行日誌記錄；如果配置不當，則有可能導致兩者出現衝突，比如：應用中也配置了ConsoleAppender，那這樣就會導致Jboss啓動時出現上面的 異常1；
所以一般來說，推薦應用中不要重複設置ConsoleAppender；如果一定要設置，則需要修改CatchSystemOut的默認值，將其顯示設置爲false，告訴Jboss無需打印來自Console的相關信息； - Java2ClassLoadingCompliance：該配置項主要是告訴Jboss在進行classload時是否採取parent first的加載策略；除了jbossweb*.sar/META-INFO/jboss-service.xml之外，還可以在應用*ar包下面的jboss-web.xml中設置<class-loading java2ClassLoadingCompliance="true">；
若設置爲true，則表示優先讓父級classloader加載相關class，如果無法加載再利用當前classloader加載；
若設置爲false，即採取child first的加載策略，表示優先讓當前classloader加載相關class，如果無法加載再委託給父級classloader加載；
注意：該配置在4.0.3的版本中有bug，具體可見：http://jira.jboss.com/jira/browse/JBAS-2347
這裏涉及到Jboss的classload機制，詳見原網店技術分享下面小飛飛在wiki中相關文章：
http://wiki.alisoft-inc.com/confluence/pages/viewpage.action?pageId=5818 - UseJBossWebLoader：該配置表明是否使用Jboss自身的classloader來加載webApp相關的資源；因爲Jboss是通過集成Tomcat來實現Web Container的，而兩者都有自己獨立的classloader；
若設置爲true，則表示Web應用加載時都將使用Jboss統一的classloader，即此時採用共享的扁平的UnifiedClassLoader；
若設置爲false，則表示Web應用採用自己獨立的WebAppClassLoader進行加載，此時Web應用和Jboss之間是完全隔離的，這也是該配置項的默認值；
