Hi David, 2010/6/10 David Bosschaert <[email protected]>: > Hi Bartek, > > One of the things I'd like to do there is investigate how far we can > get with providing infrastructure that can make both SPI providers and > clients work *without modifying the existing code*. I know this may > not be very easy, especially for clients, but at least I think we > should experiment... > > In addition I'd also like to encourage an OSGi-native model where the > SPI providers are looked up via the Service Registry... This is what > the current codebase already provides somewhat.
I fully agree - it is already possible to use the OSGi-native approach for most libraries. Only SPI anomalies still cause some problems which need to be addressed in future releases of SPI-Fly. > I will feed back results of this effort into the OSGi standardization > process so that we have standard ways of find the SPI providers in the > registry and possibly also standard ways of accessing the from > non-osgi clients. I would assume that non-osgi clients will always > have disadvantages wrt to lifecycle support. So it would be nice if we > can get as many clients over to the OSGi service registry based > approach. I hope that I'm wrong, but I feel that if poeple have choice to use either SPI-Fly with OSGi-native approach to fetching providers or modified bundles shipped with ServiceMix/Geronimo, they will choose those libraries on dope. This way they can use those APIs the same way inside an OSGi container and without it. It's hard to change people's habits :). I also think that there's one more issue with treating the services instantiated by SPI on the basis of provider bundles as fully fledged API. Some libraries use SPI to get implementations of their subcomponents. They need to fetch several implementations (impls of diifferent services) and then assemble them into a functionality that is exposed to the client. In other words service providers /implementations/ aren't fully funtional. You need the API bundle to really use the features that the given library provides. I'm not sure how many libraries are affected by this issue, but I think that javamail is one of these. I do see one work around that could make the old clients work properly, but my head starts to ache when I think about it :). The SPI-Fly extender is capable of identifying related API bundles and providers. Probably all providers need some classes/interfaces from the API bundle, so it would be possible to detect the related bundles after they are resolved. As a extender SPI-Fly gets all events related to bundle state changes. It could keep information about all the correct relationships API bundle - provider. For each API bundle it could also (using some strategy) choose a single active provider. It could then create a fragment bundle that would make all classes of the provider bundle available to the API bundle. Of course the API bundle would be the fragment host. The fragment would also need to contain a subset of files/folders that were present in META-INF directory in the provider. I won't list the drawbacks of this approach here, as my head already aches :). Best regards, Bartek
