There are problems with the servicemix attempt to osgi-ify j2ee specs too. We think we've solved all the problems and are loading classes and finding services in spec-compatible and osgi-compatible ways in the latest geronimo specs and javamail implementation. I think Rick McGuire (who investigated this very thoroughly and came up with the geronimo solution) commented on spi-fly as well.
thanks david jencks On Jun 8, 2010, at 12:23 PM, Bartosz Kowalewski wrote: > 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
