felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Watson (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (FELIX-4182) Issues with package space consistency check
Date Thu, 24 Apr 2014 14:17:14 GMT

     [ https://issues.apache.org/jira/browse/FELIX-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Thomas Watson closed FELIX-4182.


> Issues with package space consistency check
> -------------------------------------------
>                 Key: FELIX-4182
>                 URL: https://issues.apache.org/jira/browse/FELIX-4182
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>    Affects Versions: resolver-1.0.0
>         Environment: All
>            Reporter: Thomas Watson
>             Fix For: resolver-1.2.0
>         Attachments: org.apache.felix.resolver.patch
> There are two issues here.  I could separate this into two reports but I need them both
fixed at the same time and will be providing a patch shortly that addresses both of the following
> 1) ResolverImpl.resolve(ResolveContext) fails hard if a consistent class space cannot
be found for all optional resources being resolved.  It would be nice of the resolve process
could eliminate some optional resources that are the 'roots' that caused the inconsistent
class space and try again.
> 2) There is a case where a false positive inconsistency is reported for require-bundle
and split packages.  Here is the scenario
> Bundle uses.a
> Export-Package: 
>  uses1; uses:="uses2"; A="split"; mandatory:="A",
>  uses2; A="split"; mandatory:="A"
> Bundle uses.b
> Export-Package: 
>  uses1; uses:="uses2"; B="split"; mandatory:="B",
>  uses2; B="split"; mandatory:="B"
> Bundle uses.d
> Require-Bundle: uses.a, uses.b
> In this scenario, if an attempt is made to resolve uses.d then checkDynamicPackageSpaceConsistency
method will detect that uses2 is inconsistent for resource uses.d because it gets it from
two different sources uses.a and uses.b.  You get something like the following error message:
> Uses constraint violation. Unable to resolve resource uses.d [osgi.identity; osgi.identity="uses.d";
type="osgi.bundle"; version:Version="1.0.0"] because it is exposed to package 'uses2' from
resources uses.a [osgi.identity; osgi.identity="uses.a"; type="osgi.bundle"; version:Version="1.0.0"]
and uses.b [osgi.identity; osgi.identity="uses.b"; type="osgi.bundle"; version:Version="1.0.0"]
via two dependency chains.
> Chain 1:
>   uses.d [osgi.identity; osgi.identity="uses.d"; type="osgi.bundle"; version:Version="1.0.0"]
>     require: (osgi.wiring.bundle=uses.a)
>      |
>     provide: osgi.wiring.bundle: uses.a
>   uses.a [osgi.identity; osgi.identity="uses.a"; type="osgi.bundle"; version:Version="1.0.0"]
> Chain 2:
>   uses.d [osgi.identity; osgi.identity="uses.d"; type="osgi.bundle"; version:Version="1.0.0"]
>     require: (osgi.wiring.bundle=uses.b)
>      |
>     provide: osgi.wiring.bundle: uses.b
>   uses.b [osgi.identity; osgi.identity="uses.b"; type="osgi.bundle"; version:Version="1.0.0"]
> The issue is in the check for isCompatible.  This method attempts to address split packages,
but only for the provider of the split package, it does not aggregate the split sources for
clients using require-bundle to gather all the sources of the split package.

This message was sent by Atlassian JIRA

View raw message