[jboss-dev] Re: Commons-logging upgrade

[Scott M Stark]

Brian Stansberry wrote:
> Was the problem basically that the war-deployer-level mbean would call
> Log log = LogFactory.getLog(...) when the TCCL was set to the web app
> classloader? The Log type would be from conf/jboss-service.xml class
> loader level, but JCL would try to load the log adapter from the war.
> The Log interface implemented by the log adapter would be incompatible.
> JCL would detect this and throw LogConfigurationException.
Yes.

> 
> 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.