[
https://issues.apache.org/jira/browse/FELIX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941302#comment-14941302
]
Thomas Watson edited comment on FELIX-5061 at 10/2/15 4:08 PM:
---------------------------------------------------------------
Here is a possible fix. The issue is the loop used to call
ResolverImpl.checkPackageSpaceConsistency changed to only loop over host
resources. I like that change and do not suggest that we change that.
Before it used to loop over all the 'seed' resources and check their
consistency. This included any fragments that are mandatory or optional
resources according to the ResolveContext. When checking the consistency of
the fragment the impl would first find its hosts and do the check on the host,
but the original fragment resource was kept for the faulty resource and could
therefore be optionally removed from the resolution and we would retry
resolution without the fragment.
Now we have lost the context of the fragment seeds and only have their hosts
and that causes the issues. At first I was thinking we needed to somehow bring
the context back for the fragment during the consistency check, but that proved
to be overcomplicated.
Instead I decided to fix an issue with the UseConstraintError so that we report
back the Requirement that is to blame for the conflict with the host export.
That way the bit of code in ResolverImpl.checkConsistency that finds the faulty
resource will correctly detect faultyReq is a WrappedRequirement from a
fragment resource.
This also fixes an existing issue in the prior implementation that would end up
throwing out the host as well even though it could have resolved the host once
the fragment was removed from resolution.
was (Author: tjwatson):
Here is a possible fix. The issue is the loop used to call
ResolverImpl.checkPackageSpaceConsistency changed to only loop over host
resources. I like that change and do not suggest that we change that.
Before it use to loop over all the 'seed' resources and check their
consistency. This included any fragments that would mandatory or optional
resources. When checking the consistency of the fragment the impl would first
find its hosts and do the check on the host, but the original fragment resource
was kept for the faulty resource and could therefore be optionally removed from
the resolution and we would retry.
Now we have lost the context of the fragment seeds and only have their hosts
and that causes the issues. At first I was thinking we needed to somehow bring
the context back for the fragment during the consistency check, but that proved
to be overcomplicated.
Instead I decided to fix an issue with the UseConstraintError so that we report
back the Requirement that is to blame for the conflict with the host export.
That way the bit of code ResolverImpl.checkConsistency the finds the faulty
will correctly detect faultyReq is a WrappedRequirement from a fragment bundle.
> Optional resource fragment with requirements that cause class space
> consistency issues with the host export cause unexpected ResolutionExceptions
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-5061
> URL: https://issues.apache.org/jira/browse/FELIX-5061
> Project: Felix
> Issue Type: Bug
> Components: Resolver
> Affects Versions: resolver-1.6.0
> Reporter: Thomas Watson
> Attachments: FELIX-5061.patch
>
>
> Not sure if this is actually a bug in version 1.6.0. I am testing with the
> latest out of trunk so it could be something after 1.6.0.
> If a fragment contains a requirement that ultimately causes a uses constraint
> conflict with one of the hosts exported packages then the resolver will end
> up throwing a ResolutionExceptoin even when the fragment and host are
> considered to be optional resources by the ResolverContext.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
