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