You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2009/07/29 17:13:14 UTC

[jira] Created: (FELIX-1422) Resolver does not always discard partial results when a cyclically dependency fails

Resolver does not always discard partial results when a cyclically dependency fails
-----------------------------------------------------------------------------------

                 Key: FELIX-1422
                 URL: https://issues.apache.org/jira/browse/FELIX-1422
             Project: Felix
          Issue Type: Bug
          Components: Framework, Specification compliance
    Affects Versions: felix-1.8.1
            Reporter: Richard S. Hall
            Assignee: Richard S. Hall
            Priority: Minor
             Fix For: felix-2.0.0


When resolving dependencies among bundles, if a cycle is detected the resolver algorithm assumes the resolve is successful. So, assuming we want to resolve A and A wants to import from B and B wants to import from A, we end up building up a data structure where A has B as a potential candidate and B has A. If A is unable to resolve, then the whole thing fails and everything is fine. However, if the resolve starts with C and C has an optional import from A, then when A fails to resolve it is ignored since it was optional for C. This means the partial resolve results for A will be discarded, but unfortunately the partial resolve results for B are not. This means if C also has a dependency on B, the partial resolve results will be used as if they were correct, even though they include A as a candidate, which could not be resolved. The end result is an improper resolve result.

We need to remove assumptions we made about cycles if they ultimately fail to resolve.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (FELIX-1422) Resolver does not always discard partial results when a cyclically dependency fails

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard S. Hall updated FELIX-1422:
-----------------------------------

    Description: 
When resolving dependencies among bundles, if a cycle is detected the resolver algorithm assumes the resolve is successful. So, assuming we want to resolve A and A wants to import from B and B wants to import from A, we end up building up a data structure where A has B as a potential candidate and B has A. If A is unable to resolve, then the whole thing fails and everything is fine. However, if the resolve starts with C and C has an optional import from A, then when A fails to resolve it is ignored since it was optional for C. This means the partial resolve results for A will be discarded, but unfortunately the partial resolve results for B are not. This means if C also has a dependency on B, the partial resolve results will be used as if they were correct, even though they include A as a candidate, which could not be resolved. The end result is an NPE when creating wires, since it tries to create a wire to an unresolved bundle.

We need to remove assumptions we made about cycles if they ultimately fail to resolve.

  was:
When resolving dependencies among bundles, if a cycle is detected the resolver algorithm assumes the resolve is successful. So, assuming we want to resolve A and A wants to import from B and B wants to import from A, we end up building up a data structure where A has B as a potential candidate and B has A. If A is unable to resolve, then the whole thing fails and everything is fine. However, if the resolve starts with C and C has an optional import from A, then when A fails to resolve it is ignored since it was optional for C. This means the partial resolve results for A will be discarded, but unfortunately the partial resolve results for B are not. This means if C also has a dependency on B, the partial resolve results will be used as if they were correct, even though they include A as a candidate, which could not be resolved. The end result is an improper resolve result.

We need to remove assumptions we made about cycles if they ultimately fail to resolve.


> Resolver does not always discard partial results when a cyclically dependency fails
> -----------------------------------------------------------------------------------
>
>                 Key: FELIX-1422
>                 URL: https://issues.apache.org/jira/browse/FELIX-1422
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework, Specification compliance
>    Affects Versions: felix-1.8.1
>            Reporter: Richard S. Hall
>            Assignee: Richard S. Hall
>            Priority: Minor
>             Fix For: felix-2.0.0
>
>
> When resolving dependencies among bundles, if a cycle is detected the resolver algorithm assumes the resolve is successful. So, assuming we want to resolve A and A wants to import from B and B wants to import from A, we end up building up a data structure where A has B as a potential candidate and B has A. If A is unable to resolve, then the whole thing fails and everything is fine. However, if the resolve starts with C and C has an optional import from A, then when A fails to resolve it is ignored since it was optional for C. This means the partial resolve results for A will be discarded, but unfortunately the partial resolve results for B are not. This means if C also has a dependency on B, the partial resolve results will be used as if they were correct, even though they include A as a candidate, which could not be resolved. The end result is an NPE when creating wires, since it tries to create a wire to an unresolved bundle.
> We need to remove assumptions we made about cycles if they ultimately fail to resolve.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (FELIX-1422) Resolver does not always discard partial results when a cyclically dependency fails

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FELIX-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737242#action_12737242 ] 

Richard S. Hall commented on FELIX-1422:
----------------------------------------

I have committed a patch for this, which I believe works. However, I want to investigate it some more, so I will leave it open for now. The main issue is it might be too broad when removing byproduct bundles, which could result in more work being done than is actually necessary. This would still be correct, but not as efficient.

> Resolver does not always discard partial results when a cyclically dependency fails
> -----------------------------------------------------------------------------------
>
>                 Key: FELIX-1422
>                 URL: https://issues.apache.org/jira/browse/FELIX-1422
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework, Specification compliance
>    Affects Versions: felix-1.8.1
>            Reporter: Richard S. Hall
>            Assignee: Richard S. Hall
>            Priority: Minor
>             Fix For: felix-2.0.0
>
>
> When resolving dependencies among bundles, if a cycle is detected the resolver algorithm assumes the resolve is successful. So, assuming we want to resolve A and A wants to import from B and B wants to import from A, we end up building up a data structure where A has B as a potential candidate and B has A. If A is unable to resolve, then the whole thing fails and everything is fine. However, if the resolve starts with C and C has an optional import from A, then when A fails to resolve it is ignored since it was optional for C. This means the partial resolve results for A will be discarded, but unfortunately the partial resolve results for B are not. This means if C also has a dependency on B, the partial resolve results will be used as if they were correct, even though they include A as a candidate, which could not be resolved. The end result is an NPE when creating wires, since it tries to create a wire to an unresolved bundle.
> We need to remove assumptions we made about cycles if they ultimately fail to resolve.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (FELIX-1422) Resolver does not always discard partial results when a cyclically dependency fails

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard S. Hall closed FELIX-1422.
----------------------------------

    Resolution: Fixed

I modified the patch to only remove byproduct modules from actual cyclical dependencies upon failure of the cycle.

> Resolver does not always discard partial results when a cyclically dependency fails
> -----------------------------------------------------------------------------------
>
>                 Key: FELIX-1422
>                 URL: https://issues.apache.org/jira/browse/FELIX-1422
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework, Specification compliance
>    Affects Versions: felix-1.8.1
>            Reporter: Richard S. Hall
>            Assignee: Richard S. Hall
>            Priority: Minor
>             Fix For: felix-2.0.0
>
>
> When resolving dependencies among bundles, if a cycle is detected the resolver algorithm assumes the resolve is successful. So, assuming we want to resolve A and A wants to import from B and B wants to import from A, we end up building up a data structure where A has B as a potential candidate and B has A. If A is unable to resolve, then the whole thing fails and everything is fine. However, if the resolve starts with C and C has an optional import from A, then when A fails to resolve it is ignored since it was optional for C. This means the partial resolve results for A will be discarded, but unfortunately the partial resolve results for B are not. This means if C also has a dependency on B, the partial resolve results will be used as if they were correct, even though they include A as a candidate, which could not be resolved. The end result is an NPE when creating wires, since it tries to create a wire to an unresolved bundle.
> We need to remove assumptions we made about cycles if they ultimately fail to resolve.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.