cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: springification of core
Date Tue, 09 Oct 2007 12:53:05 GMT
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>> Daniel Fagerstrom wrote:
>>> Reinhard Poetz skrev:
>>>> Can you give a concrete example? E.g. the DirectoryGenerator which 
>>>> has already been springfied only exisits as a Spring bean, at least 
>>>> AFAICS.
>>> The DirectoryGenerator is still an Avalon component besides being a 
>>> Spring bean. Take a look in its super classes and you'll see that it 
>>> still implements LogEnabled, Recyclable, Poolable, Servicable and 
>>> Disposable.
>> I see. Thanks.
>>> Then you might take a look at the ResourceReader for an example of 
>>> handling of a Configurable component.
>> ok. Wouldn't it be a good idea to set dependencies this way too 
>> because in the FileGenerator I found following code:
>> try {
>>   // Lookup parser in Avalon contexts
>>   if (null == this.parser)
>>     this.parser = (SAXParser) 
>> this.manager.lookup(SAXParser.class.getName());
>> } catch (ServiceException e) {
>>     throw new ProcessingException("Exception when getting parser.", e);
>> }
>> Instead of this we could set the parser in the service() method, right?
>>                                     - o -
>> This also makes me think if we shouldn't do the Springification in a 
>> different way:
>>  1. create an Avalon free POJO that works using Spring and put it into a
>>     namespace that will also work for OSGi
>>  2. make the old component extending the new POJO and deprecate it
>>  3. implement all the necessary interfaces (LogEnabled, Configureable, 
>> etc.)
>>  4. move all the Daisy documentation which is part of the Javadocs into
>>     the new component
>> Would this work?
> You would like the old component look up the dependencies for POJO, so 
> the old component can be used directly from sitemap right?


> Apart from being tedious to implement it will work. What about the names 
> though? If we leave the old component named JXTemplateGenerator how do 
> we name the POJO one?

Sitemap components that are currently in our core are e.g. in o.a.c.generation 
which isn't the best package name anyway when they should become useable with 
OSGi. For them it shouldn't be too hard to find a better package where they fit 

But you're right, it's more difficult with components which are already at the 
right place. For the template block and the forms block we solved this by 
branching: 1.0 = Avalon -> 1.1 Spring
I think that other blocks should follow this example.

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message