tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF
Date Sun, 07 Sep 2003 03:23:21 GMT

----- Original Message ----- 
From: <remm@apache.org>
To: <jakarta-tomcat-catalina-cvs@apache.org>
Sent: Saturday, September 06, 2003 10:19 AM
Subject: cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF


> remm        2003/09/06 10:19:36
>
>   Modified:    catalina/etc bootstrap.MF
>   Log:
>   - Modify the bundling of commons-logging to fix (hopefully) the nagging
CL issues.
>   - The commons-logging-api JAR will now be put in the system classloader.
>     When using an alternate logging implmentation (ex: log4j) you should
put the
>     wrapper implementation in the same classloader or there will likely be
trouble.
>   - Ex: When using a Struts 1.1 webapp with log4j, there should be
commons-logging.jar
>     (just the log4j logger is fine as well) next to it.
>   - Of course, overriding the log4j API in a webapp is still not possible.
It wasn't
>     before as c-logging was treated as a special case by the classloader
(like JAXP).
>   - This nasty case now works for me (bug 22701), as well as using log4j
with
>     privileged webapps (with or without SSL).
>

I'm -0 on this one.  The SSL bugs were due to a non-static c-l logger (since
fixed) and/or an undefined state for the Thread ContextClassLoader.  I don't
see a use case where it is necessary to put c-l in the System Loader.


Mime
View raw message