Thanks for bringing these ideas forward - and if we can make some
progress on this we have no trouble getting you commit access and
putting you to work (like any good open source project :-D ).
Some additional comments inline ...
Wellmann, Harald wrote:
In another context, I've managed to make things work with this approach
both in a naked Java environment (i.e. putting a bunch of JARs on your
CLASSPATH) and in an OSGi environment.
My plain old Java extension lookup is based on
ServiceLoader.load(Extension.class), which is only available in Java
1.6, but what I see in Geotools FactoryFinder looks much like a
user-level implementation of ServiceLoader.
To make the ServiceLoader work in an OSGi environment, you only have to
make sure that some classes from the factory provider bundles are
visible to the factory registry bundle, either via Eclipse buddy
classloading, or via bundle fragments (which are OSGi standard and do
not only work in Eclipse).
So we have done this; the part we have trouble with is the reading of
the text files that explain what implementations are available.
I admit we can run around to all out FactoryRegistry instances (what we
are calling ServiceLoader) and register each implementation by hand... but.
- then discovery would not be automatic ..
- creation would not be lazy
Please note we have lead the ground work for this approach - the
FactoryRegistry implementations accepting a "FactoryIterator" (which
uDig could provide) allowing us to force some implementations into the
system.
Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
