[
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
