Re: [Geotools-gt2-users] geotools library as an OSGI plugin

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

Quick question; do you think those two approaches will fit behind the existing GeoTools hook for this work?

class GeoTools {
 ....
 /**
 * Adds an alternative way to search for factory implementations. {@link FactoryRegistry} has
 * a default mechanism bundled in it, which uses the content of all {@code META-INF/services}
 * directories found on the classpath. This {@code addFactoryIteratorProvider} method allows
 * to specify additional discovery algorithms. It may be useful in the context of some
 * frameworks that use the <cite>constructor injection</cite> pattern, like the
 * <a href="http://www.springframework.org/">Spring framework</a>.
 *
 * @param provider A new provider for factory iterators.
 */
public static void addFactoryIteratorProvider(final FactoryIteratorProvider provider) {
FactoryIteratorProviders.addFactoryIteratorProvider(provider);
}
...
}

Or do I need to prototype a GeoTools "Lookup" interface?

Earlier email discussion [1] had the following:

Java 1.6 has ServiceLoader outed as a public normal thread safe class rather then stuck in an out of the way corner of ServiceRegisery we use now). 

> Java 1.6 has ServiceLoader outed as a public normal thread safe class rather then stuck in an out of the way corner of ServiceRegisery we use now). 
> 
> ServiceLoader<TextFilter> filter = ServiceLoader.load(TextFilter.class); 
> for( TextFilter f : filter ){ 
> ... 
> } 
> 
> Here is the same thing done with the net beans inspried Lookup; which we may be able to use from OSGi now.... 
> 
> Collection<?extendsTextFilter> filter = Lookup.getDeafult().lookupAll( TextFilter.class ); 
> for( TextFilter f : filter ){ 
> ... 
> } 

The advantage I see is that caching of any instances happen behind the interface; so that for OSGi (where the instances
are already cached) we would have a very light wrapper.

So the interface would be something like:

interface Lookup {
<T> T lookup( Class<T> factory );
<T> List<? extends T> lookupAll( Class<T> factory );
 // <T> Result<T> lookup( Template<T> template )
 // <T> Item<T> lookupItem( Template<T> template );
 // <T> Result<T> lookupResult( Class<T> factory );
}

The methods I have commented out may or may not be useful:
- a "Template" that can be filled in allowing the search of a Factory by "id" or "interface" or whatever
- a "Result" which allows add/remove listeners, allClasses, allInstances, and "Items". I get the impression
that since OSGi allows loading/unloading of bundles this may be useful?
- an "Item" has an id, a class, an instance and a display name

References:
- http://wiki.netbeans.org/NetBeansInOSGi
- http://java.sun.com/developer/technicalArticles/javase/extensible/
- http://bits.netbeans.org/dev/javadoc/org-openide-util-lookup/org/openide/util/Lookup.html

-- 
Jody Garnett

[1] http://osgeo-org.1803224.n2.nabble.com/GeoTools-OSGi-compatibility-td5112245i20.html#a5194041
On Saturday, 23 April 2011 at 11:08 AM, whatnick wrote: 
> There are 2 possibilities for dealing with the SPI based services issue:
> 
> 1) Interceptor pattern at runtime to look at services definitions and
> generate OSGi services when a bit of text is detected - as done by the JBoss
> interceptor
> (http://docs.jboss.org/osgi/userguide/html_single/#SecServiceLoader). I
> believe such an interceptor does not need to be part of geotools per-se, but
> part of the OSGi runtime the ServiceLoader based jar's are deployed under.
> This point outlines my modifications to Mathieu's option 1.
> 
> 2) The declarative services and compile time rejigging of META-INF/services
> to OSGI-INF/*.xml - The only sore point for me here is how we are going to
> do the compile time hackery. The osgi maven plugins don't really cover this.
> May be it is time to get the Bnd author (Peter Krien's) wisdom on this
> matter.
> 
> I have a preference for option 1 but I would rather do the
> LifecycleInterceptor outside of Geotools. Thanks for the offer to prototype
> Mathieu, putting code where your mouth is.
> 
> Cheers,
> 
> Tisham.
> 
> --
> View this message in context: http://osgeo-org.1803224.n2.nabble.com/geotools-library-as-an-OSGI-plugin-tp6238602p6298586.html
> Sent from the geotools-gt2-users mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been 
> demonstrated beyond question. Learn why your peers are replacing JEE 
> containers with lightweight application servers - and what you can gain 
> from the move. http://p.sf.net/sfu/vmware-sfemails
> _______________________________________________
> Geotools-gt2-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>