Brian Stansberry wrote:

> > 1.1 is by default more robust. In this situation it detects the > incompatibility of the Log interface, but rather than throwing an > exception, it starts walking the classloader hierarchy, trying to > load the log adapter from the parent of the webapp classloader, > continuing to move up the hierarchy until it finds a compatible > adapter or no adapter is available. So, it will eventually find the > Log4jLogger loaded from server/all/lib, and that is what is returned. > This still leads to the problem of wanting to load a different log4j impl via jcl than that bound to the Log4jFactory in the parent class loader. This was the reason for the current jcl patch to allow for late binding. There is no way to deal correctly with type hierarchies that are dynamic without late binding.

> As for the test, with jcl in the war, the servlet calls Log log = > LogFactory.getLog(...) and in that case the Log interface and the > adapter are both loaded from the war. > > Perhaps a better test is to use a jsp instead of a servlet. IIRC, the > jsp processing process involves LogFactory.getLog() calls where the > Log type is loaded from the war deployer level while the TCCL is the > webapp's. I wrote some tests that used jsps and found no problems. > Those ended up in the > org.jboss.test.classloader.leak.test.ClassloaderLeakTest test case. > The problem was not the web component getting type systems confused. It was the web application mbean or some sub-mbean calling LogFactory.getLog() and having this conflict with the host mbean that was created by the tomcat deployer service. I would have to reproduce the original problem to recall exactly why the conflict arose.