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-bounces(a)lists.jboss.org wrote:
The point of the testWarCommonsLoggingLog4jOverrides was to
validate that the commons logging log4j factory does not bind
its factory at the server class loader level and prevent
resolution of the war local configuration from being used. If
the upgraded commons logging is also not working then I guess
it does need patching as well, but I thought it was supposed
to work correctly for this scenario.
The patched commons logging is in cvs.forge.jboss.com:/cvsroot/jboss
under the module apache/commons-logging.
http://fisheye.jboss.org/browse/JBoss/apache/commons-logging
Dimitris Andreadis wrote:
> We upgraded commons-logging in Branch_4_2 to v1.1
>
http://jira.jboss.com/jira/browse/JBAS-2823
>
> Now I see in the testsuite
> org.jboss.test.classloader.test.ScopingUnitTestCase failing
> (testWarCommonsLoggingLog4jOverrides), I believe due to not using a
> patched commons-logging.
>
> I guess we have to patch v1.1 as well, like in here:
>
http://jira.jboss.com/jira/browse/JBAS-3128
>
> I looked in the repository put I can't find the sources from the
> previous patch.
>
> Where are they?
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry