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 <[email protected]>: > 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, [email protected] 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 > >
