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] [Comment Edited] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions
Date Fri, 02 Oct 2015 16:08:26 GMT

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

Mime
View raw message