aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Augé (JIRA) <>
Subject [jira] [Commented] (ARIES-1739) Specifiying a version in Require-Capability prevents registration
Date Wed, 31 Oct 2018 03:43:00 GMT


Raymond Augé commented on ARIES-1739:

What I found when I started exploring this issue was that the header parsing in Aries Util
is very broken. Looking at the code I felt it was a pretty hopeless cause so I migrated the
logic to use bnd's well tested header parsing which solved this issue.

> Specifiying a version in Require-Capability prevents registration
> -----------------------------------------------------------------
>                 Key: ARIES-1739
>                 URL:
>             Project: Aries
>          Issue Type: Bug
>          Components: SPI Fly
>    Affects Versions: spifly-1.0.8
>            Reporter: Michael Lipp
>            Assignee: Raymond Augé
>            Priority: Major
> The OSGi Compendium 6.0.0 provides an example for specifying a provider:
> Require-Capability:
>     osgi.extender;
>     filter:="(&(osgi.extender=osgi.serviceloader.processor)
>     (version>=1.0)(!(version>=2.0)))"
> This fails with spi-fly because spi-fly doesn't provide a version attribute when filtering
the requirements, only the type (ProviderBundleTrackerCustomizer:390).
> The example in the spi-fly documentation does not include the version in the filter.
But it does also not warn you that adding it makes things fail. Having read the compendium
specification first, you wouldn't expect that specifying the filter has this fatal effect.

This message was sent by Atlassian JIRA

View raw message