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