aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Robinson <>
Subject Re: OSGi support for libraries that use the META-INF/services
Date Thu, 14 Jan 2010 10:27:12 GMT
One of the goals of Aries is to develop implementation to inform new 
OSGi specs so ironing out the thinking through implementation in Aries 
is a good thing.  I'd be interested in seeing this contribution.


On 14/01/2010 09:04, wrote:
> Hi David,
> I'm familiar with the work that Guillaume did for this. It shadows the
> Factory Finder of a particular implementation in the wrapping bundle
> and makes it OSGi-friendly (unless I'm wildly mistaken).
> I'm not aware of it being a separate component of itself, the SMX work
> I know is embedded in the SMX-bundles components.
> What I was thinking of is a general 'SPI-support' component that you
> could install in an OSGi framework and that would make SPI providers
> work. I'm proposing to create and collaborate of a generic component
> like this and I think Aries would be a good place to do this. I would
> welcome any contributions to it, including anything that we could
> reuse from the SMX work that Guillaume did.
> As mentioned, I'm working in parallel on a proposed standard in the
> OSGi Alliance around this and would like to use this work as input.
> I hope this makes sense...
> Best regards,
> David
> 2010/1/14 David Jencks <>:
>> I think Guillaume Nodet has implemented something like this for servicemix.
>>  I'm not sure where the code is currently but I hope we don't need more than
>> one implementation of this idea at apache.
>> thanks
>> david jencks
>> On Jan 13, 2010, at 2:46 PM, wrote:
>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message