[ https://issues.apache.org/jira/browse/FELIX-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Watson closed FELIX-4428. -------------------------------- Thanks! > 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 > Assignee: Richard S. Hall > 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)