Hi, One of the ideas behind SPI-Fly is that it could work with SPI providers that are not OSGi-aware but are bundelized. What I really would like is not to have to modify any code in the SPI. However adding an OSGi Manifest would be part of the bundelization effort (that's where the opt-in header would come in). I believe that the SMX SPI implementations actually have some additional code in the bundle, some of which shadows code in the SPI jar itself (please correct me if I'm wrong). Not too sure about the Geronimo solution does it also add new code to the SPI bundle?
There are a couple of things that spring to mind. * Maybe we can enhance the opt-in header with some instructions for non-standard SPI implementations. Besides the ones mentioned in this thread there are also examples where not the standard META-INF/services/ location is used to list the service implementations. (e.g. JavaMail seems to use META-INF/javamail.default.providers). * Another idea is to allow special handlers to be registered with SPI-Fly that know about certain specific SPI anomalies. I guess we need to figure out how many anomalies there are to decide if this makes sense, if the anomalies are confined to a small number of technologies we might want to simply build support for those into SPI-Fly... Best regards, David On 8 June 2010 20:48, David Jencks <[email protected]> wrote: > 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 > >
