cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
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

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


Mime
View raw message