cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <>
Subject Re: [RT] Separation of Blocks and Avalon
Date Thu, 09 Oct 2003 22:18:01 GMT

Stefano Mazzocchi wrote:

> On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote:
>> Rather than have cocoon blocks extend avalon blocks, I think cocoon 
>> blocks could use avalon blocks.
> Ok, I see your point.
>> Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include 
>> avalon blocks in /COB-INF/lib and delegate their deployment to the 
>> avalon container.  This could even allow cocoon blocks to provide 
>> avalon blocks to the container, as well as require them.
> I would not know how to do this! I'm not scared by merlin, I'm scared 
> about the million little details that cocoon assumes on top of ECM and 
> that are now considered deprecated by the "modern" containers. 

The million little details that cocoon assumes on top of ECM is also the 
thing that scares me the most.

> if Fortress was there, admittedly, things would be easier... but then 
> again, lots of talks, but nobody is able, wants or has 
> time/energy/braveness to do the migration.

Is there someone who provide the breakdown of what Cocoon is doing over 
and above ECM?  However things roll out - one of the biggest obsticles I 
see is that we need to move away from ECM/Fortress extension and to a 
solution where Cocoon does not need to access container APIs.  With that 
information the Avalon crowd can address how to addres these 
requirements in a way that makes the concern indpendent of the container 

>> It may help to distinguish between different types of dependencies:
>> 1. Block dependency.  As described in 
>> and 
>> specified in .  
>> What we (I think) have been talking about in several threads.
>> 2a. Avalon dependency by block.  This would be some avalon 
>> service/component that is required by the block, and would be 
>> explicitly declared.  An example might be a Transformer or the Flow 
>> engine.
>> 2b. Avalon dependency by avalon block/component/service.  This would 
>> be some avalon service that is required by an avalon service or block 
>> that is included with the cocoon block.  For example, I have a 
>> UserManager service that depends on a UserRepository service, which 
>> could be implemented by an OJBUserRepository.  If the cocoon block 
>> included the UserManager block, it might ask the Parent Component 
>> Manager for a UserManager, and might be provided with the 
>> OJBUserRepository.
> I fear the complexity of such a move. 

Break the complexity down into managable chunks.

1. migrate from Component to Object
2. migrate from roles files to meta

Just achiving the above opens up a much broader spectrum of 
possibilities and the question become much more concrete and substantive 
(from both sides of the equation). We have been discussing this over on 
Avalon land - subjects such as transition vehicles, migration tools, 
etc. these are way up on the agenda. 



Stephen J. McConnell

View raw message