cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Problem with JAXP and shielding (was Re: Shielded class loading between blocks)
Date Sun, 26 Nov 2006 11:01:17 GMT
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

Mime
View raw message