Pier Fumagalli wrote:
On 13 Apr 2005, at 18:08, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
I'm just saying that the concerns are separate: a block provides generators, transformers, serializers, ... to other blocks, but those are de-coupled from the real java components (if any) doing the job.
But *real* blocks, IIUC, *are* the only way to bring new (java) components into the system, because Cocoon core lacks all the optional components, and, at the minimum, consists only of environment, treeprocessor, and block manager.
So in extreme case xslt processor component itself is optional and provided by the xslt real block.
I think that we're mixing again the idea behind a Cocoon block and an Avalon block.
As far as I've understood Cocoon blocks (and I might be _ENTIRELY_ wrong here) Cocoon blocks do not expose (for example) an XSLT Java transformer, but expose a transformer converting a specified format into another.
AFAIU, you are entirely wrong ;) considering what have been discussed before. Neither the less, what you propose makes perfect sense to me. My idea was to start implementing the pipline part of the blocks management system, as we IMO understand enough about it to be able to work on that. Then add the possiblity to expose components and take care of class loader issues in a later step.
After having read your mails I agree that we at least for the time being, should consider component management with classloader isolation, a separate concern. By _assuming_ independence between blocks and component management, anyone who feel the itch can start working on class loader isolation right away. Then we can integrate the component management stuff in the blocks later if we feel the need. And if we don't, we saved ourself from considerable complexity.
--- o0o ---
Ok, taking a look at the technical issues. IIUC, the problem that you describe does not depend on whether a block contains Java classes or libraries or not. The problem appears as soon as a block tries to expose a component. Then the user of the component must have get all the eposed interfaces from its parent classloader. And when we add mutual dependencies between blocks and different versions of the interfaces, it start feeling more like headache than fun.
So let's take a look at some different levels of block issolation, and their properties (the pipeline is exposed in all cases):
1. No component exposing ------------------------
The block doesn't expose any components at all, not even VPCs. The block can still contain as much own Java code as it want. It gets a parent classloader with the core Cocoon functionality and adds it own classes in its own classloader. The block must obviously be compatible with the Cocoon core, but there are no version interdependencies on the Java level between blocks.
It can even expose its classloader to extending blocks without problems. The extending block must of course be compatible at the Java level with the extended one, but still no circular dependencies.
We can package the VPCs as (block) web services (ws) instead with:
VPCReader - Stream -> Stream ws VPCGenerator - Stream -> XML (SAX) ws VPCTransformer - XML -> XML ws VPCSerializer - XML -> Stream ws
by making the block protocol competent enough and introducing pipeline components that talk with the corresponding ws, we get something that works like and is as efficient as VPCs.
2. Exposing VPCs only ---------------------
Like the previous alternative but exposing VPCs. If we go for this, Sylvain's proposal about separating VPCs from other componsnts in the sitemap is preferable IMO.
3. Exposing "sitemap components" only -------------------------------------
In this alternative a block can expose components with interfaces that allready are defined in Cocoon core, or possibly a well defined subset of it. As all blocks gets a common parent classloader that contains these interfaces, we still don't get the "mutual dependency of forign blocks" nightmare.
4. Expose what you choose to ----------------------------
This is, AFAIU, the original block idea. It requires classloader isolation and dependency resolution to work.
5. Expose your classes to everyone ----------------------------------
This is what we do today. All classes/jars from blocks are loaded into a common classloader that is available for everyone. We can combine the idea of having a block aware component manager with a common classloader.
--- o0o ---
I think we can rule out alternative 5. at once. Its hard enough to get it to work today when we as a community control all the blocks. It was no accident that we choosed to move all libraries to lib/optional. There is no chance that this will scale, when external organizations start to create blocks.
Alternative 4. would maybe be nice, but as Pier I start to doubt that this is the right level of SoC, pipelines and Java components are quite different levels of abstraction. And it certainly add alot of compleity.
I would prefer alternative 1. or possibly 2. Its clean and simple and solve my current needs.
--- o0o ---
IMO, we should start simple and add functionality when needed. Remove things is much harder. Also even if we chose to go for alternative 4. an important message from Pier that we should take into account is that component exposure adds complexity. So if we go that way, we should have mechanisms that so that we can have detailed control over what components and classes a block exposes. A block that exposes much will be much more likely to create conflicts with other blocks.
/Daniel
