Details
-
New Feature
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
spifly-1.2.3
-
This feature should be able to work in all supported OSGi environments and addresses a failing that likewise occurs in all supported OSGi environments.
Description
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.
Attachments
Attachments
Issue Links
- links to
