jboss log4j冲突分析与解决

Log4j做为日志组件被大多数的系统所使用，Jboss也不例外的采用了Log4j做为它的日志输出组件。

但在使用JBoss时，不少人常常碰到一些冲突，这些冲如本身配置的log4j文件无效，系统抛org.jboss.logging.util.OnlyOnceErrorHandlerobject is not assignable to a or

g.apache.log4j.spi.ErrorHandler variable异常等。为了解决形成这方面的缘由，咱们须要分析Jboss和log4j的一些关系。本文的下面内提供了一个最佳的配置及对问题的分析，在理解了下面的内容后，相信你们都能解决log4j的冲突问题，并找到符合本身的一种解决方法。

 

1、最佳无冲突配置

解决jboss和log4j冲突的最理想配置以下：

配置jboss_server_home/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml文件里的Java2ClassLoadingCompliance及UseJBossWebLoader为false，若是存在WEB-INF/jboss-web.xml，则里面的java2ClassLoadingCompliance及java2ParentDelegaton属性也都设置成false。在webapp里log4j的配置文件采用xml形式，并命名为log4j.xml，同时在webapp的lib里须要包含log4j相关的jar包，经过这样的配置后，webapp的log4j和jboss的log4j将相互隔离互不影响。

 

2、Log4j载入配置文件的方式

Log4j在查找它的配置文件的时候，默认状况下，首先会在Classloader里查找log4j.xml文件，第一个找到的文件做为它的配置，在找不到log4j.xml文件的状况下，再查找log4j.properties文件，找到则使用这个文件，没有找到则报错。

 

3、JBoss和Log4j的关系：

关于JBoss启动和ClassLoader模型的关系，请参见:

http://blog.csdn.net/youfly/archive/2009/02/12/3884081.aspx

为了更好的理解下面的内容，若是对JBoss的启动过程和ClassLoader模型不太清楚的话，请先阅读上面的文章。

下图是jbossclassloader和相关的log4j配置文件

        Jboss classloader及相关的log4j的配置文件

 

4、JBoss启动初始化阶段

JBoss第一次使用Log4j是在JBoss Server实例初始化的时候，也即调用server.init(props)方法的时候，在这个时候JBoss线程的TCL(Thread Context ClassLoader)是NoAnotationURLClassLoader，且Server实例的定义ClassLoader也是NoAnotationURLClassLoader。所以init方法是在NoAnotataionURLClassLoader的上下文中执行，在执行时，全部的类及相关的资源文件都经过NoAnotatationURLClassLoader来装载。根据JBoss的ClassLoader模型，该ClassLoader能够载入jboss_home/lib目录下的一些jar包及bin/run.jar，具体请参考上面的文章，但它不能访问jboss_server_home/conf目录，因此这个时候没有办法访问jboss_server_home/conf/log4j.xml文件。在第一次使用Log4j时，Log4j会进行初始化，初始化时它首先查找log4j.xml文件，根据ClassLoader的委派模型，它会委派载入log4j.xml资源的请求给SystemClassLoader，这个时候若是sytem classpath里存在log4j.xml文件，Log4j将使用那个文件，若是不存在，则由NoAnotationURLClassLoader本身尝载入，它发现本身也载入不了。Log4j发现找不到log4j.xml文件后，会尝载入log4j.propertes文件，和载入xml文件时相似，它也首先进行委派载入，同理若是systemclasspath里存在log4j.properties文件，Jboss将使用system classpath里包含的文件，若是不存在NoAnotationURLClassLoader尝试本身进行载入，它能够从jboss_home/bin/run.jar里找到log4j.properties文件。run.jar包里包含的log4j.properties将JBoss内核初始化启动的调试日志输入到jboss_server_home/log/boot.log文件的定义。所以能够推断，若是在system classpath里包含log4j.xml或者log4j.properties可能会致使boot.log不能正确的写入，但不会出现什么异常。

 

5、JBoss部署阶段

Jboss使用Log4j的第二部分是在进行部署的时候，包括SAR，EAR，Jar，EJB……部署。jboss_server_home/conf/jboss-service.xml里配置的log4jService这个MBean service先对log4j进行一个初始化，在默认的配置中，log4j所用的配置文件是classpath里的log4j.xml。在log4j service初始化前，JBoss的全部日志经过都会写到boot.log中。在SARDeployer处理好jboss_server_home/conf/jboss-service.xml文件，并初始化好log4j.xml后，一般jboss的日志就会写入到server.log中。SARDeployer在初始化log4j service的时候，JBoss的线程TCL为包含patchDir(它由jboss.patch.url属性指定)和服务器conf目录的UCL。在服务器目录conf里包含一个log4j.xml文件。所以在log4j service初始化的时候一般使用conf目录下的log4j.xml（即jboss_server_home/conf/log4j.xml），但若是在system classpath包含有一个log4j.xml的话，jboss在初始化log4j时将会使用system clapsspath里的log4j.xml。这会致使server.log不正常的写入，日志的级别及写入的文件受system classpath里的log4j.xml影响。

 

6、web应用启动并服务阶段

第三部分的log4j相关的部分应该就是咱们应用开发里用到的log4j。这里只讨论Webapp的开发。根据JBoss的ClassLoader结构，在默认配置状况下，Webapp所用的ClassLoader是org.jboss.web.tomcat.tc5.WebAppClassLoader。它默认的class载入方式是先检查本身能不能载入请求的类(对于jdk核心的API则也是先请求父类载入)，若是不能载入再请求父ClassLoader载入。这个行为能够经过jboss_server_home/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml配置文件里的Java2ClassLoadingCompliance属性进行修改，若是这个属性为true，则首先检查父类能不能载入，而后再检查本身能不能载入，这个配置参数在JBossAS- 4.0.3 Final因为bug问题没有做用,bug参见：http://jira.jboss.com/jira/browse/JBAS-2347。固然它也能够经过在WEB-IN/jboss-web.xml这个文件里进行配置

<class-loading java2ClassLoadingCompliance='true'>
        <loader-repository> 
            dot.com:loader=unique-archive-name
            <loader-repository-config>
                java2ParentDelegaton=true
            </loader-repository-config>
        </loader-repository> 
   </class-loading>

或

<class-loadingjava2ClassLoadingCompliance='true'> </class-loading>

对于上一种配置，webapp将使用JBoss 隔离的UCL做为Classloader，而且是不是parent load模型是由其中的java2ParentDelegaton参数决定，java2ClassLoadingCompliance='true'属性将被忽略。对于第二次状况用的是org.jboss.web.tomcat.tc5.WebAppClassLoader，java2ClassLoadingCompliance='true'或者'false'决定了是否采用parent first模型。咱们如今来分析log4j在这里面的初始化。若是咱们在web应用里对log4j进行手动的初始化，而且初始化的配置文件没有和JBoss自己的配置文件冲突的话(如配置文件不要使用log4j.properties或log4j.xml)，通常log4j仍是能正常工做的。若是没有本身进行初始化，则采用了log4j默认的初始化流程，即首先查找log4j.xml再查找log4j.properties的方式。在webapp里调用log4j的时候，它的TCL是WebAppClassLoader，所以初始化时，首先会要求WebAppClassLoader载入log4j相关的类，在没有配置java2ClassLoadingCompliance或者java2ClassLoadingCompliance='false'的状况下。

1. 若是webapp里存在log4j的类库，WebAppClassLoader会载入该类库，因为在WebAppClassLoader里是第一次载入该类库，所以他们对log4j进行默认的初始化，它首先查找log4j.xml。

  l若是在webapp相关的classpath可以找到这个文件，则用这个文件进行初始化。

  l 不然找到委派给父Classloader进行查找，父ClassLoader UCL能够找到jboss_server_home/conf/log4j.xml文件，所以webapp相关的日志级别及输出文件都根据那个配置文件指定的规则来进行(默认配置输出到jboss_server_home/log/server.log)，但在这种状况下，每每会出现相似于下面的异常。

2008-01-22 18:43:15,868 ERROR [STDERR] log4j:ERROR A"org.jboss.logging.util.OnlyOnceErrorHandler" object is notassignable to a "or

g.apache.log4j.spi.ErrorHandler" variable.

2008-01-22 18:43:15,868 ERROR [STDERR] log4j:ERROR The class"org.apache.log4j.spi.ErrorHandler" was loaded by

2008-01-22 18:43:15,868 ERROR [STDERR] log4j:ERROR[WebappClassLoader

  delegate: false

  repositories:

    /WEB-INF/classes/

----------> Parent Classloader:

java.net.FactoryURLClassLoader@18bea70

] whereas object of type

2008-01-22 18:43:15,868 ERROR [STDERR] log4j:ERROR"org.jboss.logging.util.OnlyOnceErrorHandler" was loaded by[org.jboss.system.ser

ver.NoAnnotationURLClassLoader@ 1c 9a 690].

2008-01-22 18:43:15,923 ERROR [STDERR] log4j:ERROR Could not createan Appender. Reported error follows.

2008-01-22 18:43:15,923 ERROR [STDERR] java.lang.ClassCastException:org.jboss.logging.appender.DailyRollingFileAppender

2008-01-22 18:43:15,924 ERROR [STDERR] atorg.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:175)

2008-01-22 18:43:15,925 ERROR [STDERR] atorg.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:150)。

……………………………………………………

出现这个异常的缘由是org.jboss.logging.util.OnlyOnceErrorHandler这个类是由WebappClassLoader载入的（这是由于在webappp里存在log4j的jar包，而当前采用了child first的载入模型），而org.jboss.logging.util.OnlyOnceErrorHandler这个类在Webapp里不存在，所以它委派到了祖先ClassLoader NoAnnotationURLClassLoader来载入，NoAnnotationURLClassLoader可以载入该类，但类OnlyOnceErrorHandler的父类org.jboss.logging.util.OnlyOnceErrorHandler也是由NoAnnotationURLClassLoader载入的，它不能转化为由WebAppClassLoader载入的org.jboss.logging.util.OnlyOnceErrorHandler类型的对象，两个定义ClassLoader不一致。

2. 若是在webapp里不存在log4j的类库，log4j的相关类就是JBoss初始化log4j service时载入的类，这个时候webapp不在从新初始化log4j(由于JBoss已对log4j进行了初始化)，使用了jboss log4j service初始化的配置。

 

java2ClassLoadingCompliance=’true’的状况下，webapp使用的log4j和java2ClassLoadingCompliance=’false’的第二种状况一致，再也不详述。

 

若是jboss_server_home/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml文件里配置UseJBossWebLoader为true。因为JBoss采用了一个共享的扁平的UCL，webapp里包含的log4j.properties及log4j.xml文件通常都不会被使用，缘由是JBoss初始化的log4j service更具优先级。为了使用webapp里的配置文件，咱们须要配置webapp里的log4j配置文件到system classpath中，这个时候不论是log4j.properties仍是log4j.xml，都能被初始化，但会覆盖掉JBoss自己一些日志配置，若是是log4j.properites文件，则会覆盖boot.log日志，若是是log4j.xml，则boot.log及server.log都会被覆盖，具体缘由能够从前面的章节找到。

 

转载请注明出处: www.jfuns.com   www.jfuns.cn  http://blog.csdn.net/youfly