Fr Jeremy Krieg created ARIES-1933:
--------------------------------------
Summary: SPI Fly to allow opt-in override
Key: ARIES-1933
URL: https://issues.apache.org/jira/browse/ARIES-1933
Project: Aries
Issue Type: New Feature
Components: SPI Fly
Affects Versions: spifly-1.2.3
Environment: This feature should be able to work in all supported OSGi
environments and addresses a failing that likewise occurs in all supported OSGi
environments.
Reporter: Fr Jeremy Krieg
Fix For: spifly-1.2.3
The OSGi Service Loader Mediator spec (which SPI-Fly implements) works well as
a way for making systems based on ServiceLoader to work in an OSGi environment
in a seamless way with a minimum of effort on the part of the developer. All it
requires is to add the necessary Require/Provide-Capability headers to the
bundles in question.
Unfortunately, it seems that even this is too hard or too complicated for many
developers who are not particularly OSGi-savvy. This is the case even with
prominent libraries like the Jakarta WS implementations. Often this means we
are left with bundles that are not easy to use in an OSGi environment.
If one comes across such a bundle when trying to assemble and OSGi system, it
can be frustrating and time consuming to work around it (I know from recent
personal experience trying to get a SOAP web client up-and-running in an OSGi
environment). The ideal solution is of course to get the upstream project to
fix their metadata; however this is never straightforward nor timely. Even in
an ideal world where the bundle developers can be made to understand and
appreciate the value of adding the headers (which can of itself be a
challenge), adding new requirements to the OSGi metadata header could break
existing systems that aren't expecting it to be there and perhaps are using
some other mechanism to get it working (like Glassfish HK2 or a
ThreadContextClassLoader hack). The alternative is to create your own local
fork of the jar/bundle and fix up the metadata to include the necessary headers
for SPI Fly, but this is a significant maintenance overhead for your project.
The main reason for these difficulties is that SPI-Fly is explicitly opt-in -
that is, unless bundles already have the correct metadata definitions, SPI Fly
simply won't process them. This contrasts with (eg) Glassfish HK2, which
automatically registers all SPI Providers without them needing to opt-in.
As the SPI Fly documentation notes, bundle jars don't require any special
modifications in order for them to leverage SPI Fly - it is only the bundle's
metadata that needs changing. This means that there is no _technical_ reason
why SPI Fly needs to be opt-in: SPI Fly _could_ (like Glassfish HK2) register
all ServiceLoader implementations that it finds regardless of whether or not
they have explicitly declared that they want to be registered. In fact, because
of it's client-side support, SPI Fly could even go one better than HK2 and
automatically weave all ServiceLoader consumer bundles as well (HK2 only works
for consumers that have been explicitly written to use it).
It would break backwards compatibility of SPI Fly were to suddenly start
registering providers and weaving consumers from all bundles when it hadn't
previously. It would also (in the case of the consumer side) significantly
increase bundle load time for all bundles. So instead, I propose some
combination of the following new configuration options for SPI Fly:
* A list of bundles to register as providers, regardless of whether the
ServiceLoader Mediator require-capability headers are present. For ease of
configuration, this should include the ability to specify wildcards, regexps or
some other way of pattern matching (maybe OSGi filter syntax?).
* Ditto for consumer bundles.
* A list of bundles to to register as providers iff the require-capability
headers are present. Default is "*" (all bundles) for backward compatibility.
* Ditto for consumer bundles.
This is obviously a workaround - in an ideal world, all OSGi bundle maintainers
would understand the specs and put the right headers in their bundles. This
would enable the resolver to help people assemble the right dependencies for
their system too. However, I think at times the purist in us must give way to
the realist, and I think we unnecessarily punish the users of these bundles for
the failings of the developers if we constrain them in this way.
Thoughts/comments appreciated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
