Does javax.imageio.spi.ServiceRegistry work in an OSGi container?

Question

Can anyone tell me definitively if a osgi bundle that contains code that calls

javax.imageio.spi.ServiceRegistry

to find a service (in META-INF\service) will find that service, if that service implementation is in another bundle.

I'm not finding any documentation that is specific about this. I'm using the felix osgi container. Any pointers would be gratefully received.

I suspect it does work and my problem lies elsewhere as I notice that in the xdocreport osgi bundle fr.opensagres.xdocreport.core, ServiceRegistry gets used here but maybe its not supported on all osgi containers?

Answer 1

Hi thanks everyone for your answers. I think ServiceRegistry will work in an osgi container to instantiate a service but only within the same classloader. And that's facilitated by use of osgi fragments. So as long as the implementer is in a fragment that defines its Fragment-host as the bundle that contains the class that has the ServiceRegistry lookup code, then ServiceRegistry will work.

This is why it is working in the xdocreport code I linked to. In this case the ServiceLoader code is called from an abstract class in fr.opensagres.xdocreport.core (a bundle), which is extended by concrete class in fr.opensagres.xdocreport.document (so the ServiceRegistry call is in fr.opensagres.xdocreport.document). The Service implementation is in fr.opensagres.xdocreport.document.docx. a fragment whose has defined its frament-host as fr.opensagres.xdocreport.document.

So fr.opensagres.xdocreport.document and fr.opensagres.xdocreport.document.docx use the same class loader...so it works!

Answer 2

Out of the Box, OSGi doesn't support this, you'll need to tweak your code a bit. But there are tools around like Aries SPI Fly and Pax-Swissbox that support you in using these SPI "services"

Answer 3

No, it doesn't. I think it will only discover services in the system class loader, so that is pretty useless for bundles.

There might be a workaround, this post is pretty helpful, although I doubt if it is of any use to your problem.

Also OSGi 5 will have support for it ('Service Loader Mediator'). The reference implementation is SPI Fly from Apache Aries

Answer 4

In XDocReport we wanted have a modular API reporting to manage :

• any document kind (docx, odt, pptx...). And you can implement your own document kind if you wish and register it via javax.imageio.spi.ServiceRegistry.
• any template engine kind (Freemarker, velocity...). And you can implement your own template kind if you wish and register it via javax.imageio.spi.ServiceRegistry.
• any converter type (docx->pdf converter with POI+iText, docx->xhtml converter with POI, odt->pdf converter with ODFDOM+iText, odt->xhtml converter with ODFDOM...). And you can implement your own converter if you wish and register it via javax.imageio.spi.ServiceRegistry (ex: implement docx->pdf converter with docx4j+FOP, docx->pdf converter with JODConverter, etc).

As you have understood, javax.imageio.spi.ServiceRegistry works on OSGi context because we use OSGi fragment (share the same classloader) and not OSGi bundle. We have done this choice to manage non OSGi and OSGi context both with the same code.

We have decided to use OSGi fragment and not OSGi bundle because :

1. if we use OSGi bundle, we need to develop an OSGi Activator to register our discovery (in this context bundle, javax.imageio.spi.ServiceRegistry doesn't work).
2. if we use OSGi bundle, you need configure the start level for each bundles which register discovery.

The only disavantage to use OSGi fragment is that you cannot use in your OSGi container several version of XDocReport template, converter, document. But is it a good feature for XDocReport?

You must not that javax.imageio.spi.ServiceRegistry works with JDK5 (and JDK6). JDK6 provides java.util.ServiceLoader which is new clas to regsiter services as javax.imageio.spi.ServiceRegistry.

in XDocReport we wish to support JDK5+JDK6. XDocReport 0.9.8 used only javax.imageio.spi.ServiceRegistry. But it seems that Google App Engine forbid the use of this class (see our issue 132). So I have developped for XDocReport 1.0.0 JDKServiceLoader to manage with Java reflection both java.util.ServiceLoader and javax.imageio.spi.ServiceRegistry for JDK5 and JDK6.

Regards Angelo