[jboss-dev] Re: Commons-logging upgrade

[Scott M Stark]

What is the point of discovery not being sensitive to the caller
context? That is more of a j2se singleton behavior which is what caused
the original problem. Something has changed in the jbossweb layer to
allow jcl in the war as this originally caused conflicts between the war
deployer mbean using jcl as the conf/jboss-service.xml class loader
level, and the web app related mbeans loading jcl from the war class
loader. This combined with web app mbeans being associated with mbeans
created by the war deployer with discovery occurring in the context of
two class loaders caused type conflicts. I don't want to have to patch
jcl, but we need to understand why the test now works with jcl in the war.

Brian Stansberry wrote:
> JCL 1.1 no longer fails with LogConfigurationException if
> commons-logging.jar is deployed in WEB-INF/lib and the FilteredPackages
> thing in the tomcat sar isn't used.  If you add the jar to the
> commons-logging.war used in the test and remove
> org.apache.commons.logging from FilteredPackages, the test passes.
> 
> You can also place JCL 1.0.4 in WEB-INF/lib and the test will pass.
> 
> If we don't want to patch JCL, requiring the packaging of
> commons-logging in the war is an option.  Either way, I think filtering
> the packages is no longer necessary.
> 
> JCL doesn't late-bind the Log4j class because when it loads Log4jLogger
> (the wrapper class) it wants to get a CNFE if log4j isn't available.
> Part of the discovery algorithm.
>