最近一直忙于做一个纯技术驱动的项目：网店重生！就是要把网店版改造成为基于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之间是完全隔离的，这也是该配置项的默认值；