cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: springification of core
Date Tue, 09 Oct 2007 17:52:08 GMT
Reinhard Poetz skrev:
> 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?

That seem like a better solution, no idea of why I wrote the above code ;)

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

I think it will work. But if we start to create new components and 
deprecates the current I would like to go further:
* get rid of SitemapModelComponent - we could inject everything if we 
implement the "sitemap scope".
* get rid of or simplify XMLProducer and XMLConsumer following some of 
the ideas in Carsten's whiteboard experiment: 
http://svn.apache.org/repos/asf/cocoon/whiteboard/processor/

But that require some design discussions. I would leave that until after 
the release.

/Daniel

Mime
View raw message