geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@savoirtech.com>
Subject Re: [jira] Updated: (GERONIMO-518) Deploying Struts app fails on Logging ClassCastException
Date Fri, 30 Sep 2005 04:57:54 GMT
Bruce has shown us a great article that clearly explains the issues and 
solutions:

http://www.qos.ch/logging/classloader.jsp

It describes this problem in detail...and it says (near the bottom) for 
a solution:


"For Tomcat 5.0.27 and later,
<snip>
    4. Do not include any other copies of commons-logging.jar and 
log4j.jar in your web-applications' WEB-INF/lib/ directory.
<snip>
"


So...do we really want to hack up the classloader?  Please read the 
article..its fascinating.  Thanks for the link, Bruce.

Jeff



Bruce Snyder wrote:
> On 9/27/05, Kevan Miller <kevan.miller@gmail.com> wrote:
> 
>>Good point. I didn't notice that they were including Commons in their
>>WEB-INF/lib. I think this is related to the context-priority-classloader
>>discussion I brought up last week.
>>
>> Section 9.7.2 of the Servlet spec specifies that for a J2EE product "The
>>container should not allow applications to override or access the
>>container's implementation classes". Depending on your definition of
>>"implementation classes", Geronimo's servlet classloaders permit a number of
>>"implementation classes" (including commons-logging) to be loaded from the
>>web app's context. As this situation points out, this can lead to a number
>>of problems.
> 
> 
> The same section of the same spec also states the following:
> 
> 'It is recommended also that the application class loader be
> implemented so that classes and resources packaged within the WAR are
> loaded in preference to classes and resources residing in
> container-wide library JARs.'
> 
> Tomcat is a good exmaple of this in that it provides each webapp its
> own class loader. And therein lies the reason I have always
> recommended that each webapp should handle it's own logging (i.e.,
> contain it's own logging jars and configuration files) *completely
> separate* from the app server. I've seen far too many webapps that
> utilize the app server's logging mechanism for an individual webapp.
> IMO, this is simply wrong becuase it's using what I consider to be a
> side effect as a feature.
> 
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
> 
> The Castor Project
> http://www.castor.org/
> 
> Apache Geronimo
> http://geronimo.apache.org/

Mime
View raw message