aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: OSGi support for libraries that use the META-INF/services
Date Thu, 14 Jan 2010 09:22:31 GMT
I think this makes perfect sense. Using aries to do development for
things to be standardised in the EEG seems to be within our purview,
so I would say go for it.

Alasdair

2010/1/13  <davidb@apache.org>:
> 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
>



-- 
Alasdair Nottingham
not@apache.org

Mime
View raw message