Wellmann, Harald wrote: > Interesting, that FactoryIterator thing adds a new dimension to the > discussion. It might offer a rather seamless migration path from poor man's > META-INF service registry to the OSGi service registry. > > 1) Osgify all Geotools libraries as outlined in my wiki additions. > 2) DO NOT worry about buddy classloading, you no longer need it. (At least > not for this purpose - I'm not sure if the classloader gets (ab)used > elsewhere in Geotools...) > Only the FactorySPI system tries to work in reverse; maven is pretty good about building everything else in isolation (so the rest of the library should be without circular dependencies). > 3) Add a BundleActivator to each bundle which registers each factory > implementation as an OSGi service for the factory interface, using the > implementation class name as an additional parameter. This will not break > anything when using Geotools outside of OSGi, there is just an additional > class in the JAR which will never get loaded. (You do get a compile time > dependency on OSGi, of course.) > Okay I can follow that; any chance we can write that Activator once (to read the services file and register the implementations?). Not quite sure what you mean by "implementation class name as an additional parameter"? > 4) Extend FactoryRegistry.scanForPlugins() to also scan the OSGi service > registry for services of the given factory. (Move this code to a helper class > which will throw an exception on instantiation if there is no OSGi > environment, which you can simply catch and ignore, since in that case, all > factories should have been found by the traditional lookup method.) > I was trying to say that we have already extended the scanForPlugins() method: - we can create a FactoryIterator that scans the OSGi services. And add this FactoryIterator to the FactoryRegistry; scanForPlugins will make use of this iterator and recognize any implementations provided - we could also create a FactoryIterator that makes use of Spring context facilities - and pull the same trick for GeoServer
(the problem of recognizing implementations provided by the "Application" running GeoTools is a general problem) > 5) Encourage Geotools users to move to OSGi and directly use the service > registry. The Factory SPI system will become deprecated, but will continue to > work. > 6) Decades later, drop the deprecated Factory SPI code from Geotools. ;-) > Steps 5 & 6 sound a little optimistic; I am waiting to see the Sun vs OSGi fight resolved by the JSR process (they are trying and at least they are talking but no real progress yet). > This still does not solve the split packages issue, so you have to use > Require-Bundle and not Import-Package for dependencies between Geotools > bundles, but that would be acceptable for most users, I think. > The split-packages issue would require a code change; and I think it would be an acceptable code change. For those following along at home we have a few abstract base classes with package visibility; which are then extended by other modules (by virtue of having their implementation in the same package). This was mostly seen with org.geotools.filter base classes turning Filter into SQL as I recall. > For third-party dependencies, however, you should use Import-Package, to > avoid tying Geotools users to a particular bundle provider. > :-) > This is probably not quite the original idea of the FactoryIterator, and I > think you do not even need it with this approach: instead of registering a > FactoryIterator with the old-style FactoryRegistry, you simply rely on the > OSGi service registry to do the job. > It agrees with my understanding of FactoyIterator; ie FactoryIterator was created to help us solve this problem (and solve the similar problem when working with Spring). As of yet we have not had the time to try it out for real - perhaps you could evaluate the feasibility of this approach? Jody ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
