cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Sat, 16 Oct 2004 11:41:13 GMT
Vadim Gritsenko wrote:

> Ugo Cei wrote:
>> Il giorno 15/ott/04, alle 13:01, Vadim Gritsenko ha scritto:
>>> The best plan IMHO would be:
>>> 1. Remove ECM - implementation of Avalon container. Keep re-usable 
>>> components code (XSLT, Source, Store, etc).
>>> 2. Drop in the container which replaces it.
>>> 3. Write bridge code between container in (2) and (1).
>>> 4. Test.
>>> 5. Release Cocoon 2.3.
>>> 6. Continue with usual Cocoon development: improvements, 
>>> refactorings, as you see fit: rewrite source resolving or sitemap 
>>> processor or whatever you want if you have time for it.
>>> For a useful example of 6, Store implementation should plug in into 
>>> Java 1.5 management API instead of having background checker thread.
>> Looks like a very good plan to me.
> Do you have suggestions for (3)? Particularly, how AvalonBeanFactory 
> should be implemented, and what should be the basis for 
> ComponentSelectors?

That should be an AvalonFactoryBean, i.e. a Bean (in the Spring sense) 
that creates objects in a particular way. That FactoryBean will create 
an Avalon component, go through the various lifecycle interfaces and 
feed them as needed:
- Loggable: create a logger to a category defined by a property of the bean
- Contextualizable: pass an instance of the Context bean that should be 
declared in the container
- Serviceable: wrap the BeanFactory (the Spring container) with an 
implementation of Serviceable (see below)
- Configurable/Parameterizable: no precise idea for now. Wrap the bean's 
properties as a Configuration/Parameters object?
- Initializable: straightforward.

Serviceable components will receive a SM that translates role lookups 
into bean lookups. ServiceSelectors can be detected by checking if the 
role name is an interface name to which "Selector" has been appended. In 
that case, a ServiceSelector implementation will be returned, that will 
translate a hint to a bean name. E.g. select("file") on the selector for 
Generator will get a bean named "o.a.c.generation.Generator/file" (which 
can itself be managed by a AvalonBeanFactory).

I'd like to give a shot at this at the end of next week unless someone 
else does it before.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message