Re: [Geotools-devel] GT2 process, SPI and Spring integration

[Jody G. <jod...@gm...>]

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