aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: SPI-Fly and provider-configuration file names that are different than the abstract service class
Date Fri, 11 Jun 2010 15:25:11 GMT
On 10 June 2010 19:57, Bartosz Kowalewski <kowalewski.bartosz@gmail.com> wrote:
> Hi David,
>
> 2010/6/10 David Bosschaert <david.bosschaert@gmail.com>:
>> 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.

Yep - that would be nice. If anyone has a meaningful patch for any of
the anomalies I'd love to see it :)

>> 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 agree with the statement using the APIs the same way inside OSGi and
out, especially in the context of integrating a library in OSGi that
uses an SPI impl but wasn't written with OSGi in mind. The problem is
that the bundles in ServiceMix and Geronimo only provide a more or
less ad-hoc collection of SPI-based APIs and of those only a subset of
the available versions. The SPI mechanism is a standard pluggability
mechanism into the JRE and with the introduction of the ServiceLoader
class in Java 6 which provides generic FactoryFinder functionality
this mechanism isn't likely to go away any time soon. I would like to
experiment and see whether a _generic_ mechanism in OSGi would be
possible that would allow use of SPIs in consumers just like they
would outside of OSGi.

The main trick around the FactoryFinder/ServiceLoader is to set the
Thread Context classloader to the right classloader when
FactoryFinder.find()/ServiceLoader.load() is invoked. Although
ServiceLoader.load() has an overload that accepts a classloader we
can't assume that all clients use it.
You have already provided a fairly painful idea to how an
implementation could work (or not as the case might be;). Another idea
would be to declare in the bundle manifest what SPIs are being used
(remember we *can* modify the bundle manifest, we might be writing an
OSGi bundle or bundelizing a non-OSGi jar). Maybe some entity could
intercept the ServiceLoader.load() calls using some AOP tricks and set
the Thread context classloader to the one specified in the bundle
manifest for the duration of that call. The bundle would have to have
the right set of imports and this would possibly bind the bundle to
one particular SPI impl but then again that would highlight the
benefit of using the OSGi Service Registry instead...
Again the above is just another wild idea to add to the mix... I might
do some experimentation to see how far I can get this...

> 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.

Hmmm, is this another anomaly? It might be good to focus on the main
cases first and see if we can come up with a solution for those, maybe
the ones that use the Java 6 ServiceLoader class... We do need to
collect the corner cases too so that we don't forget about them...

> 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 :).

Ouch!

Best regards,

David

Mime
View raw message