cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <>
Subject Re: [RT] Separation of Blocks and Avalon
Date Thu, 09 Oct 2003 15:15:04 GMT
Stefano Mazzocchi wrote:

> On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote:
>> Hi,
>> I've been following the block design discussion and wiki evolution 
>> with great interest for a couple months now (blame Geoff).  Blocks 
>> look wonderful, and I can't wait to develop my cocoon based 
>> applications as blocks.
>> I have a concern about the bundling of exposed avalon services with 
>> blocks.  Specifically, in the recent thread about "Finishing the 
>> First Phase of Block Design" and on 
>> I see some 
>> duplicated effort.  As Stephen McConnell noticed, some of this 
>> functionality is already built, tested, and maintained in several 
>> avalon containers.  Why not package avalon blocks/services/components 
>> in the way the container expects, and include them somewhere like 
>> /COB-INF/lib or /COB-INF/public/lib?  Or, even cleaner separation can 
>> be had in some cases by deploying them to the avalon container 
>> independently.
>> If things are done this way, the problem noted in the thread I 
>> mentioned above could be completely avoided.  There would be no need 
>> to expose classes through the block interface because all java would 
>> be exposed as avalon services.
>> I think this would simplify the block design greatly, and allow us to 
>> focus on cocoon-specific aspects.
> Let me see if I get this right: you are proposing that we make cocoon 
> blocks
> somewhat extend avalon blocks and we have /block-inf/ for information 
> on the java components and /cob-inf/ for all the remainding 
> cocoon-specific things, in order to be able to reuse existing avalon 
> code?
> But how can I describe dependencies if one part uses implicit ones and 
> the rest uses explicit ones?
> -- 
> Stefano.
Rather than have cocoon blocks extend avalon blocks, I think cocoon 
blocks could use avalon blocks.  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.

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.

2b is the situation in which I think we could leverage the work being 
done by the various avalon containers.  We would not have to explicitly 
define transitive avalon dependencies, as the avalon container can infer 
those from the avalon block that we give to it.

Ryan Hoegg
ISIS Networks

View raw message