[
https://issues.apache.org/jira/browse/ARIES-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Augé updated ARIES-1933:
--------------------------------
Fix Version/s: (was: spifly-1.2.3)
spifly-1.2.4
> 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
> Priority: Minor
> Labels: features
> Fix For: spifly-1.2.4
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> 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)
