[
https://issues.apache.org/jira/browse/FELIX-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-4428:
-----------------------------------
Affects Version/s: resolver-1.0.0
> When inserting hosted capability from an already resolved fragment the real
> non-hosted capability is not removed as a candidate
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-4428
> URL: https://issues.apache.org/jira/browse/FELIX-4428
> Project: Felix
> Issue Type: Bug
> Components: Resolver
> Affects Versions: resolver-1.0.0
> Reporter: Thomas Watson
> Fix For: resolver-1.2.0
>
> Attachments: org.apache.felix.resolver.patch
>
>
> In Candidates there are two places where
> ResolveContext.insertHostedCapability is called:
> - org.apache.felix.resolver.Candidates.prepare(ResolveContext)
> - org.apache.felix.resolver.Candidates.processCandidates(ResolveContext,
> Resource, List<Capability>)
> In the prepare method the actual fragment capability is correctly removed as
> a candidate when inserting the hosted capability:
> List<Capability> original = ((ShadowList)
> cands).getOriginal();
> int removeIdx = original.indexOf(origCap);
> if (removeIdx != -1)
> {
> original.remove(removeIdx);
> cands.remove(removeIdx);
> }
> But in the processCandidates method this is not the case. This can lead to
> invalid Wires being created where the fragment resource is the provider.
> This happens if the hosted capability introduces a class space inconsistency
> (from uses constraints). In this case we move on to the next candidate which
> may be the fragment capability (depending on how the ResolveContext sorts).
> The fix is simple, just remove the original fragment capability from the
> candidate list. I fixed this in equinox with commit:
> http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=7efe91f3673e970f32cabc3701e99743a536da00
--
This message was sent by Atlassian JIRA
(v6.2#6252)
