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: Java components in blocks
Date Thu, 14 Apr 2005 09:16:08 GMT
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


Mime
View raw message