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 Thu, 10 Jun 2010 09:12:40 GMT
Hi Bartek,

On 9 June 2010 21:52, Bartosz Kowalewski <kowalewski.bartosz@gmail.com> wrote:
> Hi,
>
> I'm not sure how Geronimo works around the restrictions that OSGi puts
> on SPI. ServiceMix does not change the contents of the jars/bundles
> that define providers/API implementation. However, each bundle that
> provides specific API itself is slightly modified. It contains two
> extra classes - always the same two classes. They transform each such
> API bundle into an OSGI extender. Of course some modifications were
> also applied to already existing classes (the ones that used to load
> definitions from META-INF/...). Instead of loading definitions from
> META-INF/..., they use the extender.

Yeah, those modifications to existing classes were the ones I'm
talking about. It would be nice if we can make the whole thing work
without those.

> While building support for specific anomalies into SPI-Fly would
> eliminate the problems with processing provider bundles and
> registering SPI related services in the OSGi service registry, it
> would not modify the way in which API bundles detect these providers.
> It might have missed something, but I think that SPI-Fly currently
> addresses only a half of the SPI invocation. You can get SPI providers
> from the OSGi registry, but you cannot use an API that is based on
> these providers. Unfortunately, making API bundles use the OSGi
> services that SPI-Fly registers instead of the standard approach
> (classloader.getResourceAsStream("/META-INF...")) would require a
> modification in each API bundle. I guess that making those APIs work
> properly in an OSGi environment is not in scope of the SPI-Fly
> project. Am I right?

You are completely right that currently the project doesn't address
the client side. However I didn't think this to be out of scope for
SPI-Fly.

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

Best regards,

David

Mime
View raw message