4:13 p.m.
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
4:45 p.m.
New subject: Commons-logging upgrade
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.
7013
days inactive
7013
days old
jboss-development@lists.jboss.org
1 comments
2 participants
participants (2)
-
Brian Stansberry -
Scott M Stark