jboss log4j冲突分析与解决 [转]

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的冲突问题，并找到符合自己的一种解决方法。 一、最佳无冲突配置 解决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将相互隔离互不影响。   二、Log4j载入配置文件的方式 Log4j在查找它的配置文件的时候，默认情况下，首先会在Classloader里查找log4j.xml文件，第一个找到的文件作为它的配置，在找不到log4j.xml文件的情况下，再查找log4j.properties文件，找到则使用这个文件，没有找到则报错。   三、JBoss和Log4j的关系： 关于JBoss启动和ClassLoader模型的关系，请参见: http://jdeveloper.zhan.cn.yahoo.com/articles/080118/79403_24.html 为了更好的理解下面的内容，如果对JBoss的启动过程和ClassLoader模型不太清楚的话，请先阅读上面的文章。 下图是jbossclassloader和相关的log4j配置文件           Jboss classloader及相关的log4j的配置文件 四、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不能正确的写入，但不会出现什么异常。 五、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影响。   六、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都会被覆盖，具体原因可以从前面的章节找到。