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
