[
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)
