Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Thu, 9 Oct 2003 22:39:25 +0200
Subject: Re: [RT] Separation of Blocks and Avalon
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Stefano Mazzocchi <stefano@apache.org>
To: dev@cocoon.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F857B78.1030809@isisnetworks.net>
Message-Id: <ABC08676-FA98-11D7-90C3-000393D2CB02@apache.org>


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.

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.

> It may help to distinguish between different types of dependencies:
> 1. Block dependency.  As described in 
> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified 
> in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring .  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.

> 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.

True and what you describe is a sane and balanced proposal.

I just think that we should keep going with the design with have and 
with the use of the component model that we are used to and move on 
incrementally.

The machinery required to implement a component manager that is 
block-aware is very simple, probably a few lines on top of what we 
already have. even classloading should be trivial since dependencies 
are explicit.

but changing the way cocoon works in respect of component model, well, 
that's touching every single class!!! most of the cocoon developers are 
scared by this (me included), as this is the main reason why it didn't 
happen yet.

I'm willing to implement blocks, even if this means to rewrite some 
code that is already somewhere else. I might be wrong, but the 
implementation should be relatively easy (Sylvain and I discussed 
things in detail).

But moving from ECM to Fortress and from Fortress to Merlin for the 
entire cocoon component model? well, that scares the crap out of me in 
terms of number of lines of code to modify and potential bugs to 
introduce.

But if someone more knowledgble wants to do the transition, I'd be more 
than happy to be proven wrong and have cocoon move to a technology that 
is supported actively and not considered obsolete by the community 
around it.

Note, also, that your proposal is orthogonal to the implementation of 
cocoon blocks: today we use ECM and we keep use the same approach for 
java components provided by the cocoon blocks.

if in the future we change to a different java component model, we 
change it everywhere, including blocks.

if the migration is painless for cocoon own components (as it should 
be), it will be for blocks too.

the two things are, IMO, independent and can happen at different times.

--
Stefano.