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
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
Require-Capability: \ osgi.extender; \ filter:="(&(osgi.extender=osgi.serviceloader.registrar)"