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.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
