Service Loader Services Integration

This is an advanced subject.

Several bundles support the Java VM’s Service Loader services. These services have a magic file in META-INF/services with the name of an interface. If the Service Loader wants to load a service for an interface it looks in the magic directory for files with the interface’s name. It then reads the contents and loads the class with the name in that file. For example, pull-parser__pull-parser-2.1.10.jar contains the file META-INF/services/org.gjt.xpp.XmlPullParserFactory. The contents of this file is org.gjt.xpp.impl.PullParserFactoryFullImpl. Using the Service Loader to get a class that implements the org.gjt.xpp.XmlPullParserFactory interface will get you the org.gjt.xpp.impl.PullParserFactoryFullImpl class.

So let’s first add this Service Loader services file to the bundle:

-includeresource: \
	@pull-parser__pull-parser-2.1.10.jar!/PullParser*_VERSION, \
	@pull-parser__pull-parser-2.1.10.jar!/META-INF/services/*

In OSGi the Service Loader does not work because the class loader has no visibility inside your bundle. (That is the whole idea behind modularity!) However, in 133 Service Loader Mediator Specification the OSGi specifies a service that can register these Service Loader services as ordinary OSGi services.

There are different options, read the specification to see what you can do. According to the specification we must advertise the Service Loader service and then require the osgi.serviceloader.registrar extender. Again, it is useful to read the 133 Service Loader Mediator Specification or the specification.

Provide-Capability: \
	osgi.serviceloader; \
        osgi.serviceloader=org.gjt.xpp.XmlPullParserFactory

This will make the Service Loader service available to Service Loader consumers but it will not do anything unless there is a registrar present. So we need to add a requirement for the OSGi extender osgi.serviceloader.registrar:

Require-Capability: \
	osgi.extender; \
    filter:="(&(osgi.extender=osgi.serviceloader.registrar)"