You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Thomas Watson (JIRA)" <ji...@apache.org> on 2014/02/19 15:36:19 UTC

[jira] [Created] (FELIX-4428) When inserting hosted capability from an already resolved fragment the real non-hosted capability is not removed as a candidate

Thomas Watson created FELIX-4428:
------------------------------------

             Summary: 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
            Reporter: Thomas Watson


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.1.5#6160)