Title: SPI Fly This page describes the SPI Fly component. The SPI Fly component is aimed at providing general support for the JRE SPI mechanism (including the usage of META-INF/services) in OSGi. The code can be found in http://svn.apache.org/repos/asf/incubator/aries/trunk/spi-fly Currently the implementation does the following: * It only considers bundles that have the following Manifest (opt-in) header: *SPI-Provider* (the value is not used at the moment). * For every new bundle being installed that has the opt-in header, it checks the META-INF/services directory for any files. If found it registers a service in the Service Registry for each implementation found with the following property *spi.provider.url = * Additional ideas/concerns: * We need to find a mechanism to find any SPI implementations that are part of the JRE itself and register these in the Service Registry. Since there is typically not a META-INF/services file for these mechanisms nor do they implement a common interface we need another mechanism. ** Can anyone think of a generic mechanism? ** An ugly alternative could be to manually enumerate these, but this is a bit of a maintenance nightmare. * *gnodet:* 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 ... We need to support 'traditional' clients that don't look in the OSGi service registry to obtain their SPI implementation. Some ideas in this area are: * We could automatically set a System Property for every SPI implementation found. That would typically shift the 'default' choice for an implementation to the last one found. * Classloader problems around loading an implementation? * Various Lifecycle issues when using the traditional way.