You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by da...@apache.org on 2010/01/13 23:46:48 UTC
OSGi support for libraries that use the META-INF/services
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
Re: OSGi support for libraries that use the META-INF/services
Posted by Alasdair Nottingham <no...@apache.org>.
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 <da...@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
Re: OSGi support for libraries that use the META-INF/services
Posted by da...@apache.org.
Hi Guillaume,
Thanks for that!
I've added your concern to the wiki page:
http://cwiki.apache.org/confluence/display/ARIES/SPI+Fly
David
2010/1/18 Guillaume Nodet <gn...@gmail.com>:
> FWIW, the javamail spec do use the META-INF/services discovery
> mechanism, but to detect and instantiate classes using constructors
> that have arguments.
> We need to investigate if it could cause any real problem with the
> design ... or find a specific way for javamail maybe ...
>
> On Mon, Jan 18, 2010 at 15:20, <da...@apache.org> wrote:
>> Very well, then.
>>
>> For the moment, I've nicknamed my component 'SPI Fly', but I'm open to
>> any other name too.
>>
>> Currently the implementation does the following:
>> * For every new bundle being installed it checkes the
>> META-INF/services directory for any files. If found it registers a
>> service in the Service Registry with the following property
>> spi.provider.url = {the URL to the associated META-INF/services file}
>>
>> * I think it would be better to do an opt-in for the bundle. So only
>> do this when the bundle has a specific heading in its manifest (like
>> SPI-Provider or something). I will enhance the code with this shortly.
>>
>> So what's there now works fine for bundles that are aware of this
>> mechanism, clients simply look in the service registry for their SPI
>> implementations.
>>
>> It doesn't fix anything for clients that aren't aware of this feature.
>> So we need more ideas in that area...
>>
>> I would propose using the Wiki to collaborate further on the design. I've added:
>> http://cwiki.apache.org/confluence/display/ARIES/SPI+Fly
>>
>> I'll commit my code + tests to
>> https://svn.apache.org/repos/asf/incubator/aries/trunk/spi-fly soon,
>> unless someone objects...
>>
>> Best regards,
>>
>> David
>>
>> 2010/1/14 Ian Robinson <ia...@googlemail.com>:
>>> 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.
>>>
>>> Ian
>>>
>>> On 14/01/2010 09:04, davidb@apache.org 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 <da...@yahoo.com>:
>>>>
>>>>>
>>>>> 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, 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:
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: OSGi support for libraries that use the META-INF/services
Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, the javamail spec do use the META-INF/services discovery
mechanism, but to detect and instantiate classes using constructors
that have arguments.
We need to investigate if it could cause any real problem with the
design ... or find a specific way for javamail maybe ...
On Mon, Jan 18, 2010 at 15:20, <da...@apache.org> wrote:
> Very well, then.
>
> For the moment, I've nicknamed my component 'SPI Fly', but I'm open to
> any other name too.
>
> Currently the implementation does the following:
> * For every new bundle being installed it checkes the
> META-INF/services directory for any files. If found it registers a
> service in the Service Registry with the following property
> spi.provider.url = {the URL to the associated META-INF/services file}
>
> * I think it would be better to do an opt-in for the bundle. So only
> do this when the bundle has a specific heading in its manifest (like
> SPI-Provider or something). I will enhance the code with this shortly.
>
> So what's there now works fine for bundles that are aware of this
> mechanism, clients simply look in the service registry for their SPI
> implementations.
>
> It doesn't fix anything for clients that aren't aware of this feature.
> So we need more ideas in that area...
>
> I would propose using the Wiki to collaborate further on the design. I've added:
> http://cwiki.apache.org/confluence/display/ARIES/SPI+Fly
>
> I'll commit my code + tests to
> https://svn.apache.org/repos/asf/incubator/aries/trunk/spi-fly soon,
> unless someone objects...
>
> Best regards,
>
> David
>
> 2010/1/14 Ian Robinson <ia...@googlemail.com>:
>> 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.
>>
>> Ian
>>
>> On 14/01/2010 09:04, davidb@apache.org 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 <da...@yahoo.com>:
>>>
>>>>
>>>> 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, 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:
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OSGi support for libraries that use the META-INF/services
Posted by da...@apache.org.
Very well, then.
For the moment, I've nicknamed my component 'SPI Fly', but I'm open to
any other name too.
Currently the implementation does the following:
* For every new bundle being installed it checkes the
META-INF/services directory for any files. If found it registers a
service in the Service Registry with the following property
spi.provider.url = {the URL to the associated META-INF/services file}
* I think it would be better to do an opt-in for the bundle. So only
do this when the bundle has a specific heading in its manifest (like
SPI-Provider or something). I will enhance the code with this shortly.
So what's there now works fine for bundles that are aware of this
mechanism, clients simply look in the service registry for their SPI
implementations.
It doesn't fix anything for clients that aren't aware of this feature.
So we need more ideas in that area...
I would propose using the Wiki to collaborate further on the design. I've added:
http://cwiki.apache.org/confluence/display/ARIES/SPI+Fly
I'll commit my code + tests to
https://svn.apache.org/repos/asf/incubator/aries/trunk/spi-fly soon,
unless someone objects...
Best regards,
David
2010/1/14 Ian Robinson <ia...@googlemail.com>:
> 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.
>
> Ian
>
> On 14/01/2010 09:04, davidb@apache.org 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 <da...@yahoo.com>:
>>
>>>
>>> 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, 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:
>>>> 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
>>>>
>>>
>>>
>>
>>
>
Re: OSGi support for libraries that use the META-INF/services
Posted by Ian Robinson <ia...@googlemail.com>.
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.
Ian
On 14/01/2010 09:04, davidb@apache.org 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 <da...@yahoo.com>:
>
>> 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, 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:
>>> 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
>>>
>>
>
>
Re: OSGi support for libraries that use the META-INF/services
Posted by da...@apache.org.
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 <da...@yahoo.com>:
> 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, 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:
>> 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
>
>
Re: OSGi support for libraries that use the META-INF/services
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <da...@yahoo.com> wrote:
> 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, 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:
>> 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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OSGi support for libraries that use the META-INF/services
Posted by David Jencks <da...@yahoo.com>.
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, 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:
> 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