cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: ClassLoading and Cocoon 2
Date Wed, 14 Feb 2001 15:34:04 GMT
Stefano Mazzocchi wrote:
> 
> [brought Craig into the discussion since he's the classloading guru
> around here]
> 
> Berin Loritsch wrote:
> >
> > Does anyone know how to selectively load classes from a parent ClassLoader?
> >
> > I recently made Cocoon live inside it's own ClassLoader.  This is a good thing
> > as it protects us from a myriad of issues with IBM WebSphere and other Servlet
> > Containers that have wacky ClassLoaders.  However, the one thing it does not
> > protect us from is XML Parser conflicts.  If we can resolve against the Servlet
> > Engine's classes for things like javax.servlet.* and Enterprise applications,
> > but not anything else, then we are just about there.
> 
> I don't understand what you mean by parser conflicts in this case: if
> Cocoon has its own classloader and delegates to the parent only when it
> doesn't find its classes (just like Catalina does) there is no conflict.
> What am I missing?

Catalina is a Servlet 2.3 environment--where the ClassLoader is completely
separate by specification.  However, Cocoon 2 will be deployed in many Servlet 2.2
environments like WebSphere, WebLogic, JRun, ATG, Oracle, Tomcat 3.*, etc.
The issue is that if any of those Servlet containters/app servers have a
conflicting parser and JAXP implementation (like Tomcat 3.*, WebLogic, and
WebSphere), Cocoon ends up using the incorrect one.  Cocoon 2 requires a
JAXP 1.1 compliant parser--which each of the afformentioned app servers
only provide JAXP 1.0 at best.

In order for this to work in a Servlet 2.2 environment that uses it's own
parser, we need to explicitly separate Cocoon from the rest of the environment.

> 
> > One way is to explicitly handle the Parent ClassLoader separately from the
> > way the URLClassLoader handles it.  In other words, it always checks in the
> > current ClassLoader first (this does not seem to be happening), and then
> > it checks in the parent ClassLoader.
> 
> Yeah, I thought Catalina used this approach, isn't it Craig?

That's probably the way we should go then.

> Yuck. I vote for implementing a better classloader (even borrowing
> Catalina's code if possible).

Ok.  I just need implementation details.

Mime
View raw message