cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Date Mon, 10 Oct 2005 16:37:34 GMT
Carsten Ziegeler wrote:

> My point was using it for the whole webapp including the bootstrapping
> phase of Cocoon before the sitemap engine kicks in.

IMO we should use, as proposed by Carsten, the paranoid classloader combined 
with the reloading-classloader as default and get following hierarchy:

WEB-INF/classes (use reloading cl)
WEB-INF/lib (use reloading cl)
WEB-INF/blocks/[block]/classes (use reloading cl)
Context-classloader provided by the container
  -> that finally delegates to the system classloader

The only problem that we should get then is with "standard" libraries, citing 

"Such a strong shielding can have some minor inconveniences, however: if a class 
is given by the servlet engine (e.g. a JNDI context) and the same class exists 
in the webapp libs (e.g. in WEB-INF/lib/jndi.jar), then you're very likely to 
get a ClassCastException. This is likely to happen mostly with standard APIs, 
and the solution is then to delete the offending library from your WEB-INF/lib.

Why this exception? Because a class is defined by its name and its classloader. 
This means that if you get an object from the servlet engine whose class is 
defined by the engine's classloader and try to cast it to a class with the same 
class name, but loaded by the ParanoidClassLoader, the cast will fail because 
the classes are different."

As following this advice shouldn't be difficult, we should make the hierachy 
above the default setting.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:

View raw message