Wow that is fun. So it uses some tricks on the OSGi publish side: -
It also needs client code to "opt-in" using either: - static (i.e. post process your classes) - or dynamic (special OSGi class loader that injects stuff around ServiceLoader.load(Class) method) So here is what is making things strange for me; my understanding is that ... a) this would work great for GeoTools :-) We can load it up in a dynamic OSGi class loader thing that forces GeoTools to opt-in b) This may not work for ImageIO as it hooks into the image format support provided by the JRE (i.e. at a much lower level then OSGi - and I do not know how we can for the JRE to "opt-in") Still you are on to something so by all means give it a go! -- Jody Garnett On Friday, 23 December 2011 at 2:58 PM, Jody Garnett wrote: > Oh cool I was not aware of spi-fly :-) > > I also note if we can solve this problem for JAI then we can solve it for > GeoTools; which means net.refractions.udig.libs can be retired completly. > > -- > Jody Garnett > > > On Thursday, 22 December 2011 at 6:11 PM, Frank Gasdorf wrote: > > > Quite a solid objection! I assume that all the imageio-ext jars from > > geosolutions in the net.refractions.uidog.libs/lib folder using this > > SPI functionality to contribute other image format readers/writers. > > Hmm .. just found apache aries spy-fly : > > http://aries.apache.org/modules/spi-fly.html taht could be a solution > > for that. But have to investigate a bit .. > > > > Frank > > > > 2011/12/21 Jody Garnett <[email protected] > > (mailto:[email protected])>: > > > into > > > > > > > > > >
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
