[jira] [Reopened] (FELIX-5601) issues resolving with substitutable exports when the export is the last available provider

["Thomas Watson (JIRA)" <ji...@apache.org>]

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

Thomas Watson reopened FELIX-5601:
----------------------------------

I've found an issue with the current fix that needs addressed.

The original fix has issues with assuming the Candidates::m_dependenMap
is updated as the CandidateSelectors moved on to the next candidate.
An additional check is needed to make sure the current candidate is the
one that could be substituted.

This also exposed an issue with the solution for the testcase
that has a long blame requirement chain.  In this case we have
historically started at the direct requirement for the conflicting
capability and worked our way back to the root requirement for
the blame chain.
    
This worked for the most part when we didn't pay attention to
substitutable capabilities when permuting, but I suspect there
were still cases where this would eliminate.  Now that we are paying attention to substitutions there are cases where the solution will be found if we start traversing from the root -> direct requirement in the blame chain.

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