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