[
https://issues.apache.org/jira/browse/FELIX-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Watson updated FELIX-4182:
---------------------------------
Attachment: org.apache.felix.resolver.patch
Possible fix.
Fix for retry with less optional resources:
Methods changed:
ResolverImpl.resolve(ResolveContext)
When rethrow!=null there was some code to try and look at the requirements from
the rethrow and see if any of them came from optional resources and if so to
remove them. This has issues because in most cases the ResolutionException is
not getting populated with the requirements (another bug I thing). But this
also has certain issues because the rethrow only holds the very last instance
of rethrow for the last permutation checked. That may not really be the
resource you want to throw out.
This patch takes different approach by recording each 'root' resource that
results in an inconsistent class space exception for a given solution. As each
solution is checked it is determined if the solution results in less root
resources causing inconsistencies (faultyResources). At the end if no
consistent solution is found then we throw out all optional resources that are
contained in the faultyResources with the assumption that the faultyResources
is the smallest collection possible and that removing them as root resources
will result in a possible solution for the remaining optional and mandatory
resources. It is still possible that the resources removed could get pulled
back in for the next attempt, but then we will not be able to remove them again
and it should cause the resolve loop to end.
-----------------------------------------
Fix for split package class space consistency check:
Methods changed:
ResolverImpl.getPackageSourcesInternal)
With split packages it is possible to get duplicate sources added to the list.
This change just checks for duplicates to avoid that
ResolverImpl.isCompatible
Changed it to take a List<Blame> for the currentBlames since multiple
bundle-requirements may lead to multiple blames for the same package name
(multiple sources)
If there are multiple then package sources for each 'root' source is gathered
for a complete list of sources for the package. This is important for cases
where a bundle requires one or more bundles that provide the same package so
that we can get a proper list of package sources from the perspective of the
requiring bundle.
ResolverImpl.checkDynamicPackageSpaceConsistency
The changes are around the calls to isCompatible. Instead of looping over each
requirement Blame (from either a single Import-Package or a list of
Require-Bundle) the patch now considers the List<Blame> as one when calling
isCompatible with the usedBlame
If the List<Blame> turns out to cause a consistency issue then the code
iterates over each req from the List<Blame> and sees if it can permutate it
(not 100% sure if this is the right approach). Before would only permutate the
first req that caused the issue, but now that we consider them all as
contributing to the issue I decided to attempt to permutate all of them.
> 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
> Environment: All
> Reporter: Thomas Watson
> 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 issues:
> 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 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
