Hi all, I took a quick look at SPI-Fly, did some simple experiments and read this short guide: http://incubator.apache.org/aries/spi-fly.html I think that the issue with javamail that Guillaume mentioned there is not the only one that would probably need to be fixed. Javamail breaks the Jar file spec by using constructors that have arguments. The problem that I observed is a bit different. I think that the JAXB library does not break the SPI section of the Jar spec, but still cannot be properly processed by SPI-Fly. The spec suggests that the fully qualified class name should be used for the provider-configuration file name. However, I think that it's only a recommendation. The current version of SPI-Fly treats this as a requirement and not a recommendation. While SPI-Fly itself does not check if this condition is met, it uses the provider-configuration file name when registering the service. OSGi service registry will throw an exception as such a registration is not allowed.
For JAXB the service provider file name is: javax.xml.bind.JAXBContext Service implementation for this name does not need to extend any abstract class or implement any interfaces. It only needs to have a method named createContext. This might be a violation of the Jar spec. The problem of different interpretations of the Jar spec use in various APIs has been solved in ServiceMix. Each SMX bundle with 'an enhanced' spec has its own extender and uses the classname retrieved using SPI in its own specific way. In SPI-Fly there's a single extender and all detected service providers are registered in the service registry. This makes handling all those weird variations of SPI used in JRE really difficult. Best regards, Bartek
