felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-737) Resolver does not correctly discard export when module imports the same package (part 2)
Date Thu, 31 Jan 2013 15:21:13 GMT

     [ 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

Mime
View raw message