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
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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
