cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: question about jar conflicts/java class loading conflicts
Date Thu, 18 Nov 2004 18:57:58 GMT
On Thu, 18 Nov 2004 09:33:06 -0800 (PST), Ralph Goers
<> wrote:
> Sylvain Wallez said:
> > Eric Bloch wrote:
> >
> >>
> > Actually, it writing your own classloader *does* solve the problem.
> > Cocoon provided a so-called "paranoid" block providing a
> > "ParanoidCocoonServlet". This servlet loads the Cocoon servlet (or any
> > other servlet through a config in web.xml) in a ParanoidClassLoader that
> > shields the webapp's classes from the upper-level classloaders.
> >
> > Shielding means that classes and resources are always looked up _first_
> > in the webapp before delegating to the parent classloader. Up to now,
> > this has always saved my life in crazy classloading environments ;-)
> I don't believe this will save you in some environments.  I've been told
> that JBoss appears to have problems with the logging classes. I've been
> told that it expects to get them from its class loader and if it gets them
> from the webapp it seems to fall apart.

Perhaps so, but to date I've never found a need to run Cocoon using
the ParanoidClassLoader under JBoss.

There's a caveat: we're just starting to work on getting our EAR to
work under JBoss 4.  At the moment it's throwing some class not found
exceptions we didn't see under v3.  Thats likely due to some EJB class
trying to do a a lookup on a front end class that Jikes "helpfully"
copies when building the back end, prior to v4 JBoss didn't enforce
access to only EJB classes in the EJB container.  All that's to say,
as far as I can tell JBoss does things correctly....

Peter Hunsberger

View raw message