Made the project OSGI compliant

[yannickdeturck]

I made the project OSGi compliant in order to be able to use it in an OSGi environment.

[stain]

Thank you! I have merged this pull request, but didn't include the unneeded <dependency> for the osgi modules.

Did you get the ServiceLoader for the SPIs to work under OSGi?

[yannickdeturck]

Hi Stian, I've used the library for a PoC at my client. Unfortunately the decision was made to leave out the feature in our application so I never got around to test it in our OSGi environment.

[nicolas-f]

Hi, Thanks for the patch. As we will use this project in our GPL project H2GIS and OrbisGIS. We will test it in an OSGi framework. Regards,

Nicolas Fortin Lab-STICC – CNRS UMR 6285 et Ecole Centrale de Nantes GIS http://orbisgis.org Spatial DB http://h2gis.org Noise http://noisemap.orbisgis.org

[stain]

Thanks, @nicolas-f - feel free to contribute your results to issue #16 !

Here's some relevant OSGi testing framework I used in Apache Jena using pax:

https://github.com/apache/jena/tree/master/apache-jena-osgi/jena-osgi-test

[stain]

See also the release candidate 1.3.1 at #17 - feel free to test it and vote!

[nicolas-f]

Hello,

I resolved the service exports of SPI through SPI-Provider and Provide-Capability manifest tag. With the usage of Apache Aries. https://github.com/nicolas-f/h2database/blob/georaster_patch/h2/src/main/META-INF/MANIFEST.MF#L66

However I'm facing problems in the SPI consumer side. ImageIO does not found provider in other bundles..

[kojotak]

Hello,

I tried the 1.3.1 bundle, but got missing exported package: sun.security.action. What do you suggest? My ideas are:

1) edit osgi container's configuration (add system package) 2) create fragment and expose sun.security.action: see http://spring.io/blog/2009/01/19/exposing-the-boot-classpath-in-osgi/ 3) mark sun.security.action as optional and do not use the provider capability

[stain]

Thanks for testing!

I am not sure if sun.security.action is required or optional, I guess we need to grep around and check. Could you try just manually editing the manifest.mf (or pom.xml and rebuild) to make it optional?

Depending on sun.* sounds bad, but then again this code came from sun :) On 2 Nov 2015 16:26, "Tomáš Beneda" notifications@github.com wrote:

Hello,

I tried the 1.3.1 bundle, but got missing exported package: sun.security.action. What do you suggest? My ideas are:

1) edit osgi container's configuration (add system package) 2) create fragment and expose sun.security.action: see http://spring.io/blog/2009/01/19/exposing-the-boot-classpath-in-osgi/ 3) mark sun.security.action as optional and do not use the provider capability

— Reply to this email directly or view it on GitHub https://github.com/jai-imageio/jai-imageio-core/pull/13#issuecomment-153073137 .

[kojotak]

Thanks for quick reply!

Package sun.security.action is mandatory. Setting it as optional allows to bypass the export-import osgi startup check, but the provider mechanism doesn't work (as expected).

I tried to programatically instantiate an image reader (TIFFImageReader for my case), but its implementation package (com.github.jaiimageio.impl.plugins.tiff) is not exported as well.

[stain]

Thanks for having a go at my speculations :-) my apologies if I'm getting my class names wrong as I'm typing this late at night on a tablet on the train from Arlanda airport to Stockholm. :-)

Would it work to set the Thread.setContectClassLoader to yourself (which can require something from jai-imageio-core), or are we stuck because the ServiceLoader is instantiated within javax.image ? I believe you can pass in a class loader.. Perhaps getClass().getClassLoader() would do the trick?

Otherwise we would need to expose the impls as you said, or an alternative service registry instantiation.. Or perhaps marking up as proper OSGi services (which would then miss out the built in ones like JPEG reader, but we could list those in the xml)