Bah; scratch that it is GPL; however the idea may still be sound. Jody On 18/06/2010, at 4:01 PM, Jody Garnett wrote:
> 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
