classloading, using the thread context ClassLoader in OSG i is an attempt to break the
modularity rules built into the system. As a result, the consequences for using it are typ-
The awkwardness of reflection and the trickiness of the thread context ClassLoader
compound one another if you need to adapt a JAR that uses META-INF services to run
in an OSG i environment. Many libraries use this pattern to supply implementations of
an interface without tightly coupling consumers to the implementation class. The way
it works is that a ServiceLoader searches all text files in META-INF /services folders.
Files must be named after interfaces and contain the name of an implementation
class. We discussed this factory system in section 1.2.4, and concluded it was limited
compared to OSG i services. Nonetheless, it's a popular pattern, and chances are you'll
have to handle JAR s that use it.
Normally, the ServiceLoader searches the class space for resources in the META-
INF /services folder. As you saw in section 12.2.1, any JAR wanting to expose this file
must cheat and export a pseudo-package called META-INF/services . But the Ser-
viceLoader can only be wired to one META-INF/services package at a time, so the
cheat clearly won't scale well!
As if that wasn't enough of a hurdle, the ServiceLoader uses the thread context
ClassLoader to look for and load resources. We've already seen that this classloader is
undefined in OSG i. Even if one is available, it's unlikely to be able to see internal
implementation classes, unless these classes are explicitly exported from the providing
bundle. It goes without saying that exporting implementation packages is an OSG i
anti-pattern, and completely subverts the encapsulation the META-INF services pattern
was trying to achieve!
The good news is that enterprise OSG i has devised a way of making things work
without requiring pseudo-packages and exported internals. The Service Loader Medi-
ation Specification allows META-INF services to be made available through the Service
Registry with relatively non-invasive manifest changes. All that's required is an indica-
tion to the OSG i service loader extender that META-INF services should be processed.
For example, to expose a service for the shop.Bananas interface, the following should
be added to a bundle manifest:
Provide-Capability: osgi.serviceloader; osgi.serviceloader=shop.Bananas
JAR s that use the ServiceLoader.load() API can opt to have those calls magically
transformed into ones that will have the correct visibility of required implementations
in OSG i by requesting processing with a manifest header, as follows:
Search WWH ::