Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 209.85.220.214 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=K96xi6DMYSGpClLgu/QoUow+0NbkvX7c9KtY8C3+6TPCoJXw9Xk8K6XQDFzRoi1uqk
         T8ztBeACLc0ApiOkgUZOtw7+RKpCEKyzgC5kpsApTjYItt7GOE8Nx1uhFfrvhBaWdEvO
         bexvAxMz31Eb41SV6xMHvvzZ8zml1eqhXNI3s=
MIME-Version: 1.0
In-Reply-To: <EA82CA9F-F41E-4A8B-BE83-4338994549C5@yahoo.com>
References: <a1e060231001131446w2b923fcbv645a405c4d048bde@mail.gmail.com>
	 <EA82CA9F-F41E-4A8B-BE83-4338994549C5@yahoo.com>
Date: Thu, 14 Jan 2010 10:04:51 +0100
Message-ID: <b23ecedc1001140104s63de5cbamc3f8076e20e4c308@mail.gmail.com>
Subject: Re: OSGi support for libraries that use the META-INF/services
From: Guillaume Nodet <gnodet@gmail.com>
To: aries-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The code is currently located at:
   http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/
and the osgi related bits are at:
   http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator

Currently, I see 3 problems with the current code:
  * the need to change the code of the specs themselves.  This also
leads to the fact that you can't really use that for the specs that
come from the JRE itself (you need to use custom versions of those),
but I don't think we can really do anything about that
  * the inability for the client to choose its implementation through
configuration somehow
  * the fact that the dynamism of OSGi is not taken care

On Thu, Jan 14, 2010 at 02:34, David Jencks <david_jencks@yahoo.com> wrote:
> I think Guillaume Nodet has implemented something like this for servicemi=
x.
> =A0I'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, davidb@apache.org 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:
>> =A01. Look up a system property (x.y.Z) - if set use this class name
>> =A02. Look up a well known file in ${java.home}/lib (this step isn't
>> always there) - if found read the class name from it
>> =A03. 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.
>> =A04. 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
>
>


--=20
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com