RE: [jboss-dev] Re: Commons-logging upgrade
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.
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.
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.
jboss-development-bounces(a)lists.jboss.org wrote:
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.
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development