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

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

    [ https://issues.apache.org/jira/browse/FELIX-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13958825#comment-13958825 ] 

Thomas Watson commented on FELIX-737:
-------------------------------------

I fixed this in Equinox's use of the felix resolver with:

http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=217853bb6600317f28b76dd7c6521a626435f2a4

It probably could use some improvements but I needed to get *something* in here because the current behavior creates invalid wires which would be very hard to diagnose and understand if they occurred.

The basic approach I took was to find all possible candidate Capabilities that may be substituted during the prepare phase of Candidates.  Then during each permutation I check if any requirements are pointing to substituted capabilities.  If so I add a new permutation that selects the next candidate for the substitutable capability (which may be the substituted capability itself) then for the current permutation I remove the substituted capability from all other dependant requirements so they will not get wires to the substituted capability for the current permutation.

There may be a better place to do this substituted check in the consistency check, but I needed to get a basic approach working first to prevent invalid wirings from the resolver.

> 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
>             Fix For: framework-4.6.0
>
>
> 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.2#6252)