[ 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