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 http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
|