cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: springification of core
Date Tue, 09 Oct 2007 13:58:50 GMT
Reinhard Poetz wrote:
> 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?
> yes
>> 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 into.
> 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.

You're right but from what I understand both CForms and CTemplate cannot 
be currently used from sitemap level (surely CTemplate because I broke 
it myself:) )

Leszek Gawron               
CTO at MobileBox Ltd.

View raw message