aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bartosz Kowalewski <>
Subject Re: SPI-Fly and provider-configuration file names that are different than the abstract service class
Date Thu, 10 Jun 2010 18:57:07 GMT
Hi David,

2010/6/10 David Bosschaert <>:
> 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,

View raw message