geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: [jira] Updated: (GERONIMO-518) Deploying Struts app fails on Logging ClassCastException
Date Fri, 30 Sep 2005 05:56:53 GMT

Aaron Mulder wrote:
> For my part, I've never been arguing that this was a good way to
> construct an application.  I'm simply saying that if we as Geronimo
> developers insist that people change their applications to work in
> Geronimo, then we have a windmill issue.  Even if we all agree that
> putting commons logging in the WEB-INF/lib stinks, the fact is that
> people do it, and do it for the most common web framework out there,
> and those application do not break in other application servers.  In
> my opinion, RTFM is not the correct position for us to take.

I think it goes beyond RTFM...if the author is offering this as a 
solution, I find it a pretty compelling argument.

> Since we have an obvious workaround available (that is, making the
> list of packages to exclude configurable, and putting commons logging
> in there), why don't we plan to implement it?

Yes...I agree with surely will not hurt to have a configurable 
list of packages to bypass.  Its a relief valve as a minimum and gives 
the user a lot more power too...and it puts us a step ahead of the 
competition ;-)

> An alternative would be to restructure the class loaders so the client
> cannot see any server classes including logging -- where the client
> and server class loader trees are both rooted in a common class loader
> with (more or less) only the spec JARs.  I think this would be a great
> approach, and I believe there was some wider interest in looking at
> it, but it does not seem like a short-term (1.0-era) change.

This is a pretty good idea IMHO.

> Aaron
> On 9/30/05, Jeff Genender <> wrote:
>>Bruce has shown us a great article that clearly explains the issues and
>>It describes this problem in detail...and it says (near the bottom) for
>>a solution:
>>"For Tomcat 5.0.27 and later,
>>    4. Do not include any other copies of commons-logging.jar and
>>log4j.jar in your web-applications' WEB-INF/lib/ directory.
>> we really want to hack up the classloader?  Please read the
>>article..its fascinating.  Thanks for the link, Bruce.
>>Bruce Snyder wrote:
>>>On 9/27/05, Kevan Miller <> 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
>>>>"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.
>>>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
>>>Apache Geronimo

View raw message