geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: [jira] Updated: (GERONIMO-518) Deploying Struts app fails on Logging ClassCastException
Date Fri, 30 Sep 2005 05:38:28 GMT
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.

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?

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.


On 9/30/05, Jeff Genender <> wrote:
> Bruce has shown us a great article that clearly explains the issues and
> solutions:
> 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>
> "
> 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 <> 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
> >
> >
> > Apache Geronimo
> >

View raw message