Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Tue, 28 Mar 2017 21:50:41 +0000 (UTC)
From: "Thomas Watson (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.13059603.1490668745000.147680.1490737841626@Atlassian.JIRA>
In-Reply-To: <JIRA.13059603.1490668745000@Atlassian.JIRA>
References: <JIRA.13059603.1490668745000@Atlassian.JIRA> <JIRA.13059603.1490668745318@jira-lw-us.apache.org>
Subject: [jira] [Resolved] (FELIX-5601) issues resolving with substitutable
 exports when the export is the last available provider
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 28 Mar 2017 21:50:45 -0000


     [ https://issues.apache.org/jira/browse/FELIX-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Watson resolved FELIX-5601.
----------------------------------
    Resolution: Fixed

I fixed this by doing an additional check in Candidates::canRemoveCandidate that makes sure the current candidate of the dependent CandidateSelector is the candidate that is about to be substituted.

I also did the change to traverse the blame requirement chain from direct->root and root->direct requirement to be sure to find a solution if it exists.  This was necessary to pass the test testScenario18 which has a blame chain with 4 reqs.

> issues resolving with substitutable exports when the export is the last available provider
> ------------------------------------------------------------------------------------------
>
>                 Key: FELIX-5601
>                 URL: https://issues.apache.org/jira/browse/FELIX-5601
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>            Reporter: Thomas Watson
>            Assignee: Thomas Watson
>
> Substitutable exports that are used by other exported packages can cause a case where a valid solution cannot be found when one exists.  The issue only can occur when a substitutable export is the only valid candidate left for a resources mandatory requirement and the resolver decides to permute the substitutable requirement becaused of a used blame.  Something like the following resources
> resource A1
>   provides pkg X v1
>   provides pkg Y v1 uses->X
>   provides pkg Z v1 uses->Y
> resource A2
>   provides pkg X v2
>   provides pkg Y v2 uses->X
>   provides pkg Z v2 uses->Y
>   import pkg X v[2,4)
>   import pkg Y v[2,4)
>   import pkg Z v[2,4)
> resource A3
>   provides pkg X v3
>   provides pkg Y v3 uses->X
>   provides pkg Z v3 uses->Y
>   import pkg X v[2,4)
>   import pkg Y v[2,4)
>   import pkg Z v[2,4)
> resource B1
>   provides pkg W v1 uses->Z
>   import pkg Z v[1,4)
> resource C1
>   imports pkg X v[3,4)
> Resolve all resources A1, A2, A3, B1, C1 as mandatory resources.  This will result in resolution error for B1 because it is exposed to two versions of X through two uses blame chains.  The reason this fails is because the resolver first chooses to permute the substitutable requirement from A3 for X which causes X v3 to no longer be available for C1 to import.  This causes an error and the permutation fails and all other permutations based off that permutation will be ignored.  If instead the resolver would not permute the requirement for X from A3 the resolver would find a valid solution.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)