[
https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14705581#comment-14705581
]
Thomas Watson commented on FELIX-4987:
--------------------------------------
This does seem to solve my problems. One question on the fix. The new method
org.apache.felix.resolver.Candidates.getHosts() is misleading because it can
return fragment resources. I assume this is not your intention?
It seems to me that you need additional (!Util.isFragment(res)) checks in each
loop before putting the resource in the hosts map.
> 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)
