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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
