[ 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)