Carsten Ziegeler skrev:
...
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.
How would that work? Running an xslt-transformer within a block local
class loader (using an block local Xalan and Xerces) is one thing.
Exposing the xslt-transformer to the rest of the blocks is something
entirely different, we have no mechanism for that.
To achieve this you need a mechanism where you can configure what
classes (or packages) that should be exported from a block classloader
and what should be local. You also need a mechanism for importing
classes to a block classloader from other block classloaders.
We have nothing like this in Cocoon.
/Daniel
