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
lot.
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.
Pier
|