felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-4428) When inserting hosted capability from an already resolved fragment the real non-hosted capability is not removed as a candidate
Date Thu, 24 Apr 2014 20:17:14 GMT

     [ 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)

Mime
View raw message