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: felix-1.2.1
Reporter: Richard S. Hall
Assignee: Richard S. Hall
Fix For: felix-1.2.2
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.
-
You can reply to this email to add a comment to the issue online.
