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 Tue, 27 Sep 2005 19:18:31 GMT
> 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.
>>>From my previous note, here's the current list of restrictions for each
> ClassLoader.
> TomcatClassLoader:
> java, javax, org/apache/geronimo, org/apache/jasper, org/apache/tomcat,
> org/apache/naming, org/apache/catalina, org/xml, org/w3c
> JettyClassLoader:
> java, javax, org/apache/geronimo, org/mortbay, org/xml, org/w3c
> Seems like we need to make a concerted effort to identify the Geronimo
> implementation" classes and prevent them from being loaded from a
> servlet's
> context...
> One meta-question -- I note that Jeff has moved this from a "Jira"
> discussion to a "dev" discussion (which I've maintained). What's the
> process, here? After consensus is reached in "dev", is that then captured
> in
> the Jira?

Yes.  I opened this up for discussion to get people's input before we do
something in JIRA.  I would be apt to close the issue as INVALID, as its
not a Struts issue at all, but a clashing of classloaders/jar versions.
But I wanted to get everyone's thoughts on this before doing something to
the JIRA entry.

Relative to your comments on the classloader...I agree with some of your
points.  However, the commons logging has a slightly different twist.  I
would assume we want the web app to use the Geronimo version since its
Geronimo who is ultimately responsible for logging, not the web app.
IMHO, I think having the commons logging jar in the WEB-INF/lib is a
no-no...and this problem plagues many other app servers...and is not
unique to Geronimo.  We could make the context-class-loader to allow
additional declarative packages (in the plan file) to use the proper
loader...and that's about the only other solution I can come up with
(other than just removing the jar from the WEB0INF/lib dir).

View raw message