cocoon-dev mailing list archives

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

> The only problem that we should get then is with "standard" libraries, citing 
> Sylvain:
> "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.
The good thing about Maven is that you can define "provided" for a
dependency and in this case, the dependency is not copied into
web-inf/lib or included in your block. So as long as you are configuring
your dependencies correctly, this should not happen very often.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message