Hi all,

One of the things that seems to be coming up regularly is the support
in OSGi for libraries that make use of what is often referred to as
the JRE SPI model. This model is used in many pluggable technologies
coming out of the JCP and typically involves a FactoryFinder or the
ServiceLoader class. Some technologies that use this mechanism are
JAXP, JAXB, JAXWS, JAXRS, media codecs and many more...

Generally this model causes problems in OSGi, mostly because in OSGi
it's impossible to export-package META-INF/services from multiple
bundles (well you can export it multiple times, but a consumer will
only ever get linked to a single one) and also because the mechanism
doesn't take the OSGi Classloaders into account.
There are a number FactoryFinder implementations in the JRE, they vary
slightly but in general they try to do two things:

A. Find the class name of a factory implementation of technology X.
The factory implements/subclasses an interface/class called x.y.Z.
They roughly take the following steps:
  1. Look up a system property (x.y.Z) - if set use this class name
  2. Look up a well known file in ${java.home}/lib (this step isn't
always there) - if found read the class name from it
  3. Load a resource called META-INF/services/x.y.Z using
ClassLoader.getResource(). Typically the ThreadContext classloader is
tried as well as the system classloader. Sometimes a classloader is
passed in to the Finder. If the resource can be loaded, read class
name from it.
  4. If all of the above fails, use a default hardcoded classname

B. Once the classname has been obtained the FactoryFinder will try to
load that class using either a provided classloader, the Thread
Context Classloader or the system classloader.

OSGi has solutions for a few individual cases of this problem. E.g.
the XML Parser Specification handles this for JAXP, but rather than
having to write a spec for every single use of this I'd rather like to
see if we can come up with a generic solution to this problem.

Therefore I'd like to propose an Aries component to address this issue
in a generic manner. I've written a small extender that scans bundles
for META-INF/services files, instantiating any services found and
registering them with the OSGi Service Registry.
While this doesn't cover use-cases yet for clients that use the
JRE-style lookup (generally through a static method), but it does
provide some value to OSGi aware clients as they can look up their
services in the Service Registry.
What I have is just a starting point, I'd like to see how far we can
get building this out, hopefully also supporting the traditional
client lookup scenarios.

Ultimately once we have something that works this can be brought into
the OSGi Alliance as input in the standardization process, so that
hopefully at some point we'll have a standard covering this issue
nicely.

So... does the Aries community think this would be a useful component
to work on? If so I can commit my code and tests, and we can
collaborate on it from there...

Best regards,

David

Reply via email to