[jboss-user] [Installation, Configuration & DEPLOYMENT] - Re: JBoss log4j Update Required?

[munikuntla]

T 11-5 log4j:ERROR A "XYZAppender" object is not assignable to a "org.apache.log4j.Appender" variable. 

This error occurs when log4j classes are loaded into memory by two distinct class loaders. According to section 4.3.4 of the Java Language Specification, when the same class is loaded by different class loaders, the resulting runtime copies are con-sidered incompatible.  

While processing configuration scripts, log4j configurators often load classes into memory. Log4j is programmed such that configurators will first attempt load a re-quired class using the thread context class loader (TCL) and if that fails, it will at-tempt to load the class using the current class loader. Thus, log4j configurators will fail to load appenders or other log4j components when the thread context class loader has a different copy of log4j classes than the copy loaded by the current class loader. For example, assuming class loaders A and B both load a copy of log4j classes and the TCL is set to point to B, then invoking the configure method of a  DOMConfigurator instance loaded by class loader A will cause an error. Indeed, the method responsible for loading the appender into memory will check that the class of the appender is assignable to org.apache.log4j.Appender. The check is done against the org.apache.log4j.Appender class loaded by A but since log4j gives preference to loading classes through the thread context class loader, B in this case, the Java runtime will consider the new appender (loaded by B) incom-patible with the copy of org.apache.log4j.Appender class loaded by A. 

To get around this problem it suffices to make sure that only one and only one copy of log4j.jar is available to the class loader hierarchy of your application. This is not always possible because certain servlet containers and EJB containers use log4j in-ternally for their own logging. These containers usually ship with a copy of log4j.jar which is visible by certain parts of their class loader hierarchy. However, when users deploy 
log4j.jar within their web-applications or ear files, depending on the delegation model of the application-specific class loaders as well as the TCL settings, con-flicts can arise. Tracking these conflicts requires good understanding of the class loader hierarchy of the container as well as precise details about the deployment of jar files at user premises. It is not always possible to obtain accurate and timely in-formation on these matters.  

When all attempts to resolve the aforementioned problem fail despite your best ef-forts, then you can set the "log4j.ignoreTCL" system property as a last ditch solu-tion. When this system property is set to any value other than "false," log4j's class loading algorithm will ignore the value of the thread context loader and will only use the current class loader in order to locate and load classes. Note that the "log4j.ignoreTCL" property is only available in log4j version 1.2.6 and later. It is a system property that cannot be specified within configuration files.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203365#4203365

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203365