Uploaded image for project: 'Aries'
  1. Aries
  2. ARIES-1933

SPI Fly to allow opt-in override

Details

    • New Feature
    • Status: Resolved
    • Minor
    • Resolution: Fixed
    • spifly-1.2.3
    • spifly-1.3.0
    • SPI Fly
    • 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

        Issue Links

          Activity

            rotty3000 Raymond Augé added a comment -

            I've played with this and implemented it for the most part.

            My biggest concern is that it opens another window for start ordering issues, whereas strict requirements on Service Loader Mediator paired with a framework extension does incur start order issue. But that's no worse than some of the other models that SPI Fly already supports such as dynamic bundle mode.

            rotty3000 Raymond Augé added a comment - I've played with this and implemented it for the most part. My biggest concern is that it opens another window for start ordering issues, whereas strict requirements on Service Loader Mediator paired with a framework extension does incur start order issue. But that's no worse than some of the other models that SPI Fly already supports such as dynamic bundle mode.

            Commit 9fbf63c4c7776dc4586395dc444b740b0bbc5671 in aries's branch refs/heads/ARIES-1933 from Raymond Augé
            [ https://gitbox.apache.org/repos/asf?p=aries.git;h=9fbf63c ]

            ARIES-1933 manual opt-in

            Signed-off-by: Raymond Augé <rotty3000@apache.org>

            jira-bot ASF subversion and git services added a comment - Commit 9fbf63c4c7776dc4586395dc444b740b0bbc5671 in aries's branch refs/heads/ ARIES-1933 from Raymond Augé [ https://gitbox.apache.org/repos/asf?p=aries.git;h=9fbf63c ] ARIES-1933 manual opt-in Signed-off-by: Raymond Augé <rotty3000@apache.org>

            Commit 9fbf63c4c7776dc4586395dc444b740b0bbc5671 in aries's branch refs/heads/trunk from Raymond Augé
            [ https://gitbox.apache.org/repos/asf?p=aries.git;h=9fbf63c ]

            ARIES-1933 manual opt-in

            Signed-off-by: Raymond Augé <rotty3000@apache.org>

            jira-bot ASF subversion and git services added a comment - Commit 9fbf63c4c7776dc4586395dc444b740b0bbc5671 in aries's branch refs/heads/trunk from Raymond Augé [ https://gitbox.apache.org/repos/asf?p=aries.git;h=9fbf63c ] ARIES-1933 manual opt-in Signed-off-by: Raymond Augé <rotty3000@apache.org>

            Commit fd1fb363b64dba9224239e94bd71ab2cf0c0fb1c in aries's branch refs/heads/trunk from Raymond Augé
            [ https://gitbox.apache.org/repos/asf?p=aries.git;h=fd1fb36 ]

            Merge pull request #106 from rotty3000/ARIES-1933

            ARIES-1933 manual opt-in

            jira-bot ASF subversion and git services added a comment - Commit fd1fb363b64dba9224239e94bd71ab2cf0c0fb1c in aries's branch refs/heads/trunk from Raymond Augé [ https://gitbox.apache.org/repos/asf?p=aries.git;h=fd1fb36 ] Merge pull request #106 from rotty3000/ ARIES-1933 ARIES-1933 manual opt-in

            Commit fd1fb363b64dba9224239e94bd71ab2cf0c0fb1c in aries's branch refs/heads/trunk from Raymond Augé
            [ https://gitbox.apache.org/repos/asf?p=aries.git;h=fd1fb36 ]

            Merge pull request #106 from rotty3000/ARIES-1933

            ARIES-1933 manual opt-in

            jira-bot ASF subversion and git services added a comment - Commit fd1fb363b64dba9224239e94bd71ab2cf0c0fb1c in aries's branch refs/heads/trunk from Raymond Augé [ https://gitbox.apache.org/repos/asf?p=aries.git;h=fd1fb36 ] Merge pull request #106 from rotty3000/ ARIES-1933 ARIES-1933 manual opt-in
            rotty3000 Raymond Augé added a comment -

            Two framework/system properties are available:

            • org.apache.aries.spifly.auto.consumers - provide a comma delimited set of ant style globs to match on Bundle-SymbolicName. Matches are treated as though they had specified requirements of osgi.extender; filter:='(osgi.extender=osgi.serviceloader.processor)',osgi.serviceloader;filter:='(osgi.serviceloader=*)'. The syntax matches that of Export-Package header, however attributes and directives are ignored.
            • org.apache.aries.spifly.auto.providers - provide a comma delimited set of ant style globs to match on Bundle-SymbolicName. Matches are treated as though they had specified requirements of osgi.extender; filter:='(osgi.extender=osgi.serviceloader.registrar)' and a capability for each provider type discovered in the bundle, like osgi.serviceloader;osgi.serviceloader='<type>';<attributes/directives>. The syntax matches that of Export-Package header. Attributes and directives defined on the matching glob are added to the capability.
            rotty3000 Raymond Augé added a comment - Two framework/system properties are available: org.apache.aries.spifly.auto.consumers - provide a comma delimited set of ant style globs to match on Bundle-SymbolicName . Matches are treated as though they had specified requirements of osgi.extender; filter:='(osgi.extender=osgi.serviceloader.processor)',osgi.serviceloader;filter:='(osgi.serviceloader=*)' . The syntax matches that of Export-Package header, however attributes and directives are ignored. org.apache.aries.spifly.auto.providers - provide a comma delimited set of ant style globs to match on Bundle-SymbolicName . Matches are treated as though they had specified requirements of osgi.extender; filter:='(osgi.extender=osgi.serviceloader.registrar)' and a capability for each provider type discovered in the bundle, like osgi.serviceloader;osgi.serviceloader='<type>';<attributes/directives> . The syntax matches that of Export-Package header. Attributes and directives defined on the matching glob are added to the capability.

            People

              rotty3000 Raymond Augé
              kriegfrj Fr Jeremy Krieg
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 72h
                  72h
                  Remaining:
                  Remaining Estimate - 71h 50m
                  71h 50m
                  Logged:
                  Remaining Estimate - 71h 50m
                  10m