Thanks for the discussion Andrea; I have a new more details in line; but the
rest may need to wait for actual experimentation.
> > 1) Factory SPI does not work
> >
> > I think the approach recommended in the OSGi discussion can work here;
> > basically set up a Lookup class with different backends in the same design
> > as we used for Logging.
>
> Sounds like a reasonable approach. There is always the catch of maintaining
> whatever makes the various implementations "tick". I can see us maintaining
> the SPI files and have some tooling to generate whatever config file is
> needed for the rest?
That was the trust of the other email discussion with OSGi; they were a bit
worried about the different expectations expected by the different
plugin systems. For some reason they had the impression that Factory SPI was
"class" based. In fact we get an instance of each class returned to us; which
should align with what they are used to.
> > Additional thoughts:
> > - separate out "plugin" (allowing the abilities of a jar to be recognised)
> > from "factory" (keeping some instances based on their configuration)
> Don't follow here.
Let me find a real example:
1. Perhaps I should of said "service providers" rather than "plugin". This is
what SPI does; it expects to find a class with a no argument constructor;
and it will return us an instance of that class.
2. The idea of a factory is an object with a bunch of create methods; we have a
habit of configuring our factories for use (using hints)
We often (such as in the case of referencing) try to combine these two uses
with sometimes amusing to debug results).
> > - may need the equivalent of an an Activator (allowing a plugin to
> > "register" and "deregister" as needed)
> As in, dynamically, at run time, OSGI style? That can be challenging, we have
> lots of static initialization blocks.
We actually have some facilities in place already; but I don't trust them. The
ability to "scanForPlugins", the ability to register a FactoryProviderIterator,
and some support for "listening" to see if things change.
> > - proof of concept could include SPI solution (by default) and example of
> > a direct configuration ( for use by andriod), code woudl not be considered
> > complete until the OSGi crew had shown they could work with it
> >
> > I am pretty sure this could be done with out disrupting existing
> > implementations.
> Yep, that's fundamental.
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
