Alexander Klimetschek wrote:
> The problem also exists without my ShieldingBlockServlet, I just tested
> serving jsps from a sitemap that is part of a normal cocoon webapp with
> shielding done by the deployer plugin and the same exception pops up
> upon requesting the jsp.
>
> The actual bug is that the cocoon-jsp block does not work with any kind
> of shielding, since it uses the jasper jsp engine provided by the webapp
> and that one expects its own JAXP implementation. The jasper jsp engine
> can be loaded, but during compiling of a jsp it tries to load some JAXP
> class, which fails, because that loading is done by the shielding
> classloader, which has another version of Xerces and xalan. (IIRC, the
> latter point is the reason for shielding anyway, since many
> transformation stuff done with cocoon sitemaps does not work with older
> XSLT implementations provided by the webapp container - some really
> annoying problem we already stepped into).
Yepp, you're right of course - so just forget my last answer.
>
> A solution to that kind of problem is not easy. The first idea would be
> to explicitly check for the classloader in the cocoon JSP component
> before executing the Jasper enginge, but how do you find out if you got
> a shielding classloader or not? You cannot cast, not for the
> ShieldingClassLoader which will be part of the maven-war-plugin you
> don't want to have a dependency to, and also not for the
> WebappClassLoader, because that one is webapp container specific (and
> there is no API for that in the servlet specs).
>
> So a dirty Hack would be to do a check like
>
> ClassLoader cl = this.getClass().getClassLoader();
> // step over all shielding class loaders to find the webapp classloader
> while (cl.getClass().getName().indexOf("Shielded")) {
> cl = cl.getParent();
> }
>
> // set cl as context classloader
> // start jsp engine
>
>
> Looks kinda ugly....
>
Definitly - now, what about adding the jasper engine to the classpath of
the webapp
by putting it in web-inf/lib?
Looking at this scenario, I have the feeling that sooner or later you
hit similar problems in other cases as well. As soon as you access
something the container provides for you, you might end up with the same
mess.
So, perhaps we have to take a step back and think, why we think that
shielded class loading is a great feature. One reason is commons logging
(which should be solved with newer versions) and the other one is the
endorsed problem with Xalan and Xerces as the most promintent candidates.
Perhaps our blocks concept helps here? If our xslt transformer would be
in its separate block using its own class loader with its own version of
Xalan, the problem would be solved as well. Everything else could run in
the webapp classloader.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
