Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4172C9D1.9050208@nada.kth.se>
Date: Sun, 17 Oct 2004 21:36:49 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
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>
In-Reply-To: <41729D39.5010002@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:

<snip/>

> While I agree with your concerns, I think a DI container can 
> _potentially_ bring a lot in this area. The current problem with 
> Cocoon's xconf file is that it is really free-form, and the variety of 
> the components makes writing an XML grammar to check it near to 
> impossible. Furthermore, each component picks up the information it 
> needs in the configuration it is given and silently ignores what it 
> doesn't care about (including typos of otherwise valid configurations!).
>
> Combine this with the fact that docs are often incomplete and you have 
> a good overview of why I most often go reading code of the configure() 
> method to know what a component expects, and also why many users start 
> shuddering when they have to change something in cocoon.xconf.
>
> Now with DI, components have to be JavaBeans and their configuration 
> has to be formally described using methods. The JavaBeans framework 
> has been providing lots of interesting features for years to 
> introspect classes and provide users with meaningful information for 
> them to setup their objects (remember the good old BeanBox?). Each 
> class can also provide its own BeanInfo object where it further 
> describes its expectations with some additional human-oriented data. 

I agree about that current state of configuration handling is far from 
perfect, I also read the code in the configure methods from time to 
time. The problems that you describe _could_ be solved in an 
evolutionary and admittedly less sexy way. We could write better 
documentation ;) And by writing some configation validation tools that 
can be used in the configure methods in the components, we could make it 
easier to refactor the current components to become responsible citizens.

> What this means is DI allows us to:
> - formally check the configuration file
> - automatically produce the configuration documentation for each 
> component (with the distinction of "preferred" and "expert" properties 
> as defined by FeatureDescriptor [1])
> - write tools to assist users in setting up the system. 

If we decided to write Cocoon from scratch, this might be better than 
what we have. But to me, it sounds like a major rewrite, is it 
worthwhile? Does Spring support all this?

> Now you're right that leaving to non-technical users the 
> responsibility to wire components will frighten a lot of them and may 
> endanger the stability of the system. I raised this issue in the past. 
> But there are some solutions to this.
>
> A first solution is to leverage the BeanContext API [2] as a 
> container-agnostic interface to perform some lookup-based wiring. We 
> can then consider that only values of primitive types are configurable 
> through the configuration file. That's roughly what we have today, but 
> still somehow hardcodes the wiring of dependencies. 

I read your blog about using the BeanContext API as the generic 
component management API, it sounds like a rather attractive idea to me. 
>From a quick glance at it, I get the impression that it is rather "fat" 
compared to the ServiceManager API. Is it a good API? How large part of 
it do you need to implement?

If one where to build a "generic" container from scratch, the DI pattern 
is probably a slightly better idea than the "service locator" pattern, 
still they solve the same problem and they booth has advantages as well 
as disadvantages, (http://www.martinfowler.com/articles/injection.html). 
As we currently use the service locator pattern for general component 
look up and interface based DI for a choosen few, I wonder if it would 
be worthwhile to change pattern everywhere. Of course the service 
locator is slightly less flexible than DI, but is that a disadvantage 
for us?

> A second one is to have a layered configuration system: a built-in 
> configuration file (possibly one for each component or for each 
> "module" that we currently call "blocks") defines some default values 
> and wirings for component properties, along with their lifestyle and 
> lifecycle. The user-written configuration file then simply overrides 
> some of these default values. That allows to have a running Cocoon 
> with an empty configuration file (all defaults are used) while 
> allowing users to override the properties they need to, feel the need 
> to depending on their knowledge. 

Sound like a good idea, does Spring support it?

> How does that sound? 

Sylvain, I think that you have excelent technical solutions to the 
problems. And I would love to share your and others entusiasm for a 
revolution ;) But don't let us fool ourselves, what you and others 
suggest sound like a large amount of work. And the apperent simplicity 
that one felt while reading about the "Hello World" example in the 
documentation about Spring is starting to fade away. We will probably 
have to use Spring in a non-standard way. We will have to work quite 
alot to keep backward compability. We will be unstable for a prolonged 
period.

So my quite boring question is: is it worth it, will we gain that much?

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.


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

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.

/Daniel

>
>
> Sylvain
>
> [1] 
> http://java.sun.com/j2se/1.4.2/docs/api/java/beans/FeatureDescriptor.html
> [2] http://www.anyware-tech.com/blogs/sylvain/archives/000141.html
>