On 24/07/2010, at 6:13 PM, Andrea Aime wrote: > The first approach I tried was creating its own factory iterator > provider. This works sort of fine, but there is a catch: > the spring context can be started and stopped multiple > times, each time a different factory bean will be created, > and the old one must be removed.
Bleck! > However, the moment you get access to FactoryRegistry, you can > also directly register a factory using > FactoryRegistry.registerServiceProvider > Long story short, the provider iterators are useless for > an effective Spring integration because of the different > lifecycle handling between the two systems. Cool; well that is what we needed to know. We added them ages ago to see if they would do the trick for OSGi or Spring; this is the first solid feedback. > Attached there is a class that uses a Spring callback to register > and deregister itself from SPI at the right time. > To work it requires Processors to expose methods to do so (exposing > the factory registry directly is not the best idea encapsulation > wise, and the methods also need to cater for the fact Processors > caches the last factory). > Attached there is a patch to add the necessary helper methods. The patch looks clear. > Opinions? A while ago I looked at netbeans "Lookup" which has been used as a front end for OSGi, netbeans, FactorySPI and I think Spring. I think we could mirror the design; it would look similar to providing a "FactoryFinder" rather then a FactoryIterator. So Spring would load and unload the FactoryFinder it contributed. But yeah we also depend on FactoryRegistery to cache instances for reuse; so I would assume we would need the contributed FactoryFinder to mirror this responsibility. Jody ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
