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
