[
https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-4987.
------------------------------------
Resolution: Fixed
Assignee: Guillaume Nodet
Fix Version/s: resolver-1.6.0
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M resolver/src/main/java/org/apache/felix/resolver/Candidates.java
M
resolver/src/main/java/org/apache/felix/resolver/ResolverImpl.java
M
resolver/src/test/java/org/apache/felix/resolver/test/ResolverTest.java
Committed r1696779
The above commit seems to fix the use cases mentioned.
Could you please double check ?
> Dynamic package resolution with unresolvable or fragment package exports can
> lead to invalid wirings
> ----------------------------------------------------------------------------------------------------
>
> Key: FELIX-4987
> URL: https://issues.apache.org/jira/browse/FELIX-4987
> Project: Felix
> Issue Type: Bug
> Components: Resolver
> Environment: All
> Reporter: Thomas Watson
> Assignee: Guillaume Nodet
> Fix For: resolver-1.6.0
>
>
> With the latest code in trunk calling
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Resource,
> Requirement, List<Capability>) with a List<Capability> containing a
> Capability from a fragment will lead to an invalid Wire.
> This looks similar to FELIX-4897 and appears to be a regression.
> There are two types of failures.
> 1) Where the fragment has a valid host to resolve against. In this case I
> would expect the Wire.getProvider() to be the host revision for the fragment,
> but the current code returns the fragment revision
> 2) Where the fragment has no valid host available. In this case I would
> expect no Wire to be returned in the result from the ResolverImpl.resolve
> call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
