cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Directory structure of blocks
Date Wed, 13 Apr 2005 15:22:06 GMT
On 13 Apr 2005, at 15:07, Vadim Gritsenko wrote:

> Carsten Ziegeler wrote:
>> Pier Fumagalli wrote:
>>> classloading cumbersomeness...
> (probably you meant flexibility here? ;-P)
> <snip/>
>> Ok, long story, short question: do we plan to support such scenaries
>> with real blocks? I really hope so :)
> As Pier outlined in snipped parts above, it's achievable goal. We 
> would have to build blocks hierarchy, and corresponding classloader 
> hierarchy. Interface blocks are going to be loaded by parent 
> classloader, while implementation block(s) and consumer block(s) will 
> have own child classloaders.
> This gives level of isolation necessary to run different version of 
> hybernate (or what have you) within same Cocoon core.
> Just a thought... If we allow consumer block's classloader to have 
> multiple parents, which are classloaders of all interface blocks, then 
> this will free us up from building block hierarchies.

Correct, but if right now you take out components, classes and 
libraries out of the blocks, and start thinking about blocks as 
providers of VIRTUAL components (Xalan library + XSLT, I18N Library + 
catalog.xml), where the java components are required by the block, and 
exposed as a virtual component to other blocks, we simplify the whole 

And separating the two concerns of loading up the libraries in an order 
that makes sense (and is usable), versus loading blocks and deploying 
them simplifies the whole trick.

Let's assume that we have two interfaces: the ForrestSkin interface. It 
"provides" to its users a "Document2HTML" transformer.

In ForrestSkin version 1 requires something that transforms DocumentV1 
to HTML, and ForrestSkin version 2 requires something that transforms 
DocumentV2 to HTML, we can have right now, without thinking about 
classes, two blocks, both requiring the XSLT component (Java, but it's 
the same instance, no versioning issues), one associating it with 
document2htmlv1.xsl and one associating it with document2htmlv2.xsl.

And we live the much more cumbersome work of loading the XSLT 
Java-based transformer to ECM+++/Kernel/Spring/Pico/YouNameIt, once we 
start seeing what are the JAva requirements that the block deployment 
forces on to the underlying machinery.


View raw message