[
https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14703112#comment-14703112
]
Guillaume Nodet commented on FELIX-4987:
----------------------------------------
For #1, the behaviour has not changed afaik. I tried a simple test with the
previous resolver, and it also returns the fragment as the provider. I don't
mind changing that behavior, but it's not really a regression imho.
For #2 and #3, I think there are some test cases available in equinox. I've
cloned the https://git.eclipse.org/r/equinox/rt.equinox.bundles git repo, but I
run into some build issues. Could you give me the steps to run your tests
please ?
Also, as a side question, can you confirm that a dynamic resolution can lead to
fragments being attached to new hosts and new hosts to be resolved ?
> 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
>
> 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)
