[jira] [Closed] (FELIX-737) Resolver does not correctly discard export when module imports the same package (part 2)

["Karl Pauls (JIRA)" <ji...@apache.org>]

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

Karl Pauls closed FELIX-737.
----------------------------
       Resolution: Fixed
    Fix Version/s:     (was: framework-5.6.4)

This likely doesn't apply anymore - hence, I'm closing this issue. Let's create a new one if this still needs to be addressed by the framework at a later point.

> Resolver does not correctly discard export when module imports the same package (part 2)
> ----------------------------------------------------------------------------------------
>
>                 Key: FELIX-737
>                 URL: https://issues.apache.org/jira/browse/FELIX-737
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework, Specification compliance
>    Affects Versions: framework-1.2.1
>            Reporter: Richard S. Hall
>            Assignee: Richard S. Hall
>
> FELIX-736 addressed a related aspect of this issue, it dealt with making sure that the capabilities of resolved bundles are correctly recorded so that attempts to resolve subsequent bundles do not see the discarded export, when a resolved bundle both exports and imports the same package and is wired to a provider other than itself.
> The resolver is also affected by a similar bug during the resolve process itself, when it resolves transitively dependent modules. The way the resolver works is that it creates a list of all possible candidates to resolve every requirement for all transitively dependent modules. Unfortunately, some candidates might not actually be candidates because their exports might be discarded at the end if they both import and export the same package and are wired to some other provider. In this case, the export is discarded so any other transitively dependent bundles that were using the discarded export as a candidate are no longer valid. Currently, the resolver lets these bundles wire to the discarded export, which is not correct.
> I think the only way to fix this is during the class consistency checking phase of the resolver. During that phase we loop through all combinations of candidates to find a consistent class space. We must extend this phase to also look to see if a candidate for a requirement has been discarded and if it has then we must ignore it and try another.
> This will be a little tricky since we must make sure that we do not disturb the ordered candidate permutation of the class space checking phase, since it is the only way we know that we have tried all combinations. I think what we will need to do is if we notice an invalid candidate, we will have to locally permutate that candidate, but remember that we did so if we get a class consistency error we can set the local permutation back to the previous value so that the global permutation can continue.
> This probably doesn't make sense to anyone, but me, so I will stop now. :-)



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