aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Augé (Jira) <j...@apache.org>
Subject [jira] [Commented] (ARIES-1933) SPI Fly to allow opt-in override
Date Mon, 25 May 2020 15:59:00 GMT

    [ https://issues.apache.org/jira/browse/ARIES-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116128#comment-17116128
] 

Raymond Augé commented on ARIES-1933:
-------------------------------------

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.

> 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
>            Assignee: Raymond Augé
>            Priority: Minor
>              Labels: features
>             Fix For: spifly-1.3.0
>
>   Original Estimate: 72h
>          Time Spent: 10m
>  Remaining Estimate: 71h 50m
>
> 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)

Mime
View raw message