Re: [jboss-dev] Re: Commons-logging upgrade
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.