Re: [Geotools-devel] OSGi: first simple example with referencing factories working

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

This is my replacement for FactoryProvider FactoryIteratorProvider (and for the current FactoryRegistery). Figure if I am maintaining the gt-metadata data module it may as well contain code I don't hate.

The important part here is that at the end of the data this is an internal change to the FactoryFinder classes; and the existing GeoTools factory implementations should be able to used unmodified (once with a no argument constructor; and once with their crazy "Hints" constructor).

However if you were not looking at OSGi integration I would be ignoring this and working on process; as it is this is a bit of a weekend project for me (as LISAsoft now has a hacked up version of GeoTools turning over on Andriod with 70% of the code thrown away etc...).

-- 
Jody Garnett


On Friday, 3 June 2011 at 1:09 AM, Mathieu Baudier wrote:

> > From the javadocs of my uncommitted work (you can see the code example
> > showing the separation). The Lookup provides a listener api allowing the
> > registery to notice when an implementation is no longer available (due to a
> > bundle being unloaded I presume). The Lookup only deals with providing an
> > implementation (ie a no argument constructor or reference by some kind of
> > string id) and is general purpose.
> 
> This sounds very promising, but I would need to get my hands dirty
> before I really understands it.
> When do you think that you would be able to commit a first version of
> this in the branch?
> This should go pretty fast to integrate the new OSGi code with this
> approach and see if it addresses the current issues.
> 
> I kind of feel that there may be an abstraction level which is not
> needed between Lookup, Factory, FactoryProvider,
> FactoryIteratorProvider, etc.
> This is just a guts feeling.
> 
> > The Register is GeoTools factory specific; willing to deal with the Hints
> > system (and have several instances of a Factory configured differently).
> 
> The system of Hints reminds me of the service properties used to
> distinguish between OSGi services implementing the same interface.
> (simple String key/value pairs)
> You can then reference OSGi services by defining filters on their
> service properties.
> 
> Maybe we should make sure that the two concepts are properly connected.
> 
> Is it necessary that Hints extends java.awt.RenderingHints ?
> It is a bit surprising to see a dependency on an UI library at this level.
> 
> I'm just raising all the points I have in mind, while we are
> brainstorming on a development branch...
> 
> Cheers,
> 
> Mathieu