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
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
