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 <[email protected]>: > 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, <[email protected]> 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 <[email protected]>: >>> 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, [email protected] 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 <[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 >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
