[jboss-dev] Re: Commons-logging upgrade

[Brian Stansberry]

jboss-development-bounces at lists.jboss.org wrote:
> Brian Stansberry wrote:
<snip>
>> 
>> 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.
> 

Yes. I didn't mean to imply the late binding patch no longer had value;
just that allowing the loading of JCL classes from the war removes a
large category of cases where it is needed. I also wanted to hijack the
thread a bit to get into whether the FilteredPackages was still needed.
:-)

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

I can't remember exactly what it was either. I do remember it was
readily apparent. But, with the late-binding patch I don't see how the
FilteredPackages thing does any significant harm, so perhaps leaving
well enough alone is the way to go.

Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry