felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Watson (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (FELIX-5601) issues resolving with substitutable exports when the export is the last available provider
Date Tue, 28 Mar 2017 21:50:41 GMT

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

Mime
View raw message