Hunted down the implementation:
- http://wiki.netbeans.org/NetBeansInOSGi
And a presentation by the guy who wrote it:
-
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 ){
...
}
Andrea this impacts on your request to go to Java 6. ServiceLoader (what we
have used for ages) is finally public; however by using Lookup we could:
- avoid Java 6 longer
- allow the getDefault() to be supplied based on application environment
- The OSGi happy implementation uses the same META_INF/services stuff as
geotools has now
Implementation:
- http://kenai.com/projects/osgilookups
Talk:
- http://www.devoxx.com/display/DV09/Lookup+-+A+new+OSGi+Service+Registry
The above implementation apparently is a drop in replacement and should be able
to use what geotools is doing already :-)
Jody
On 18/06/2010, at 3:03 PM, Jody Garnett wrote:
> Okay here is a slightly wilder idea; combined with a very good article:
>
> Article first with a nice background on Factory SPI moving on to the netbeans
> LookUp (think container, inversion of control etc...)
> - http://java.sun.com/developer/technicalArticles/javase/extensible/
>
> NetBeans has suffered another release [1]; this one supporting two things of
> interest:
> - OSGi integration
> - LookUp is now a separate module
>
> So I wonder how they made LookUp work in an OSGi environment? It is the same
> problem we face.
> Jody
>
>
> [1] http://java.dzone.com/articles/best-netbeans-69
>
> On 18/06/2010, at 6:17 AM, Mathieu Baudier wrote:
>
>>> Mathieu - one thing that may help is that we have all our GeoTools code
>>> using the same "factoryregistery" class to check factory spi (and to hold
>>> onto a singleton of each factory found). We have extended this factory
>>> registery in a few cases to allow people to "register" additional
>>> implementations.
>>
>> This is interesting.
>> That would probably be the right place to do tricks with the context
>> class loader.
>>
>> Where is (are) this code located?
>>
>>> So perhaps:
>>> - we could try generating additional entries for the MANIFEST.MF based on
>>> the services/ directory
>>> - we could process these additional entries of the MANIFEST.MF and
>>> "register" these additional factories with the appropriate register
>>
>> I don't really get what you mean here.
>> Could you please be a bit more explicit? (like with an example)
>>
>> What do you think of the approach with the fragments that I described
>> in my previous mail?
>> Is this what you are thinking of?
>> (I usually solve many of my OSGi problems with fragments)
>
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
