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

Richard S. Hall updated FELIX-737:
----------------------------------

    Fix Version/s:     (was: framework-4.2.0)
                   framework-4.4.0
    
> 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.4.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to