Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4172E532.7040506@apache.org>
Date: Sun, 17 Oct 2004 23:33:38 +0200
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Some notes about the "Real Blocks" issue
References: <41715565.8070309@dslextreme.com> <4172447E.1000107@s-und-n.de>
 <41728E49.3070908@nada.kth.se> <41729D39.5010002@apache.org>
 <4172C9D1.9050208@nada.kth.se>
In-Reply-To: <4172C9D1.9050208@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:


<snip/>

> What I would like us to do, is to write some kind of (prioritized) 
> requirement list on what problems we would like to solve for 
> intra-block component handling. Then it would be possible to evaluate 
> different technical solutions with respect to our requirements. Or 
> maybe what the problems are, and that Spring will solve them is 
> allready obvious ;)
>
> A list of possible problems with my very tentative solution for it:
>
> * P: I'd like to use my favourite light weight component container 
> (FLWCC) for writing my business logic.
>   S: It is already possible.
>
> * P: I'd like to use components from FLWCC from within Cocoon components.
>   S: Could be done by having a "hook" for pluging in external 
> component containers in the CocoonComponentManager.
>
> * P: I'd like to start using DI style while writing Cocoon components.
>   S: Could be done by copying ECM to the Cocoon SVN and extend it with 
> some basic DI functionality. After all ECM is not that much code and 
> it is deprecated anyway, no one would care.
>
> * P: The configuration validation sucks.
>   S: See above.
>
> * P: I don't trust Avalon. I hate everything that they stands for, and 
> seeing the name in a class path reminds me of how they have destroyd 
> my life ;)
>   S: Avalon is dead. The framework code and ECM resides in Excalibur, 
> and Excalibur is more or less sleaping. We are the main user of the 
> API:s and they are not under development. If Excalibur wakes upp and 
> become hostile, we can have a own copy of the framework API.
>
> * P: Spring or another DI container is necessary or will make it much 
> easier to implement real blocks.
>   Ok, now we are talking, please explain why and how.
>
> Add your reasons.


Since Avalon came to life and I came to love it, I've had long fights 
with some of my colleagues at work to convince them to use it, in order 
to have robust architectures. Their argument was that they didn't want 
to use Avalon because of its viral nature: once you start using it, you 
have to use it everywhere and your code no more can be used outside an 
Avalon container. Although I wanted to promote Avalon as a way to have 
an homogeneous way to hold the various parts of a project, I also 
understood their arguments.

State of the art has evolved, and strangely we can consider that the 
writing style that DI brings us is in some ways going back at a time 
where COP did not existed, where people were writing spaghetti plates 
dependencies. DI simply allows us to have spaghetti plugs in our classes 
and it actually wires the spaghetti plate, without enforcing a rigid 
structure where you must fit or go away. In some way, DI allows to 
manage the chaos.

Now I understand all your concerns about the revolution this may lead 
to, and I recognize I may be a bit over-enthusiastic. If you read the 
archives (e.g. [1]), I wasn't that happy at first. But my mind evolved 
as I was looking at Spring and all the cool features it provides. Sure, 
these features may only be really useful for business logic, but why not 
also for Cocoon components?

This is still theoretical, but I have the feeling we can make this 
revolution in a smooth way, by facading a Spring container with an 
Avalon container implementation. I'll spend some times on this in the 
coming weeks, and we'll see what comes out of it.

>>> Now what IMO is important is inter-block component handling. That 
>>> will get us new and much needed functionality in form of "real 
>>> blocks". And refactoring Cocoon to use Spring will not help us a bit 
>>> in geting in this direction, AFAIU, as we need class loader 
>>> isolation for that. And there are no containers featuring class 
>>> loader isolation out there, except for Pier's one, IIUC.
>>
>>
>> Intra and inter-blocks are different concerns, but they are both 
>> discussed here because we have the opportunity to have a unified way 
>> of writing components in a container-independent way, which the death 
>> of Avalon makes a must have for Cocoon. 
>
>
> IMHO the inter-block component handling is where we can gain most, and 
> nearly all discussion (my included) is about intra-block component 
> handling. I wonder why. I am all for progress, but if we are going to 
> make a revolution I think there should be _really_ strong reasons for 
> it. I would much prefer an evolutionary path, adding small things, and 
> refactoring along the way.


As I told above, the evolutionary path seems to be possible, and I am 
too concerned by the need of a smooth transition.

> The death of Avalon doesn't force us to do anything in the short term. 
> Actually it takes away part of our previous problems, no one is going 
> to do anything hostile about the API anymore. And if we feel that we 
> must develop it we can steal it without upsetting anybody.


You're totally right. The death of Avalon makes us free to do whatever 
we want with these APIs. Now the question is: do we want to live with a 
dead thing when we have more lively alternatives in front of us?

Also, from a marketing point of view, how will you explain to a customer 
that the foundations Cocoon components are built upon are a project that 
has been closed?

Sylvain

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108964393220564&w=2

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }