[jira] [Commented] (FELIX-5251) Resolver impl is in need of extensive cleanup

["Thomas Watson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278591#comment-15278591 ] 

Thomas Watson commented on FELIX-5251:
--------------------------------------

I committed my changes with:

http://svn.apache.org/viewvc?view=revision&revision=1743238

This also fixed an issue where the resolver would attempt to attach fragment to an already resolved host.  I put a safeguard in the code to prevent that from happening.  The code is not able to handle doing proper class space consistency checks to an existing host wiring that gets updated with pay-load requirements and capabilities from a fragment.  There are lots of assumptions in the code that depend on fragments only getting attached to hosts that are being resolved during the current resolve process.

I updated the existing test that seemed to depend on the old behavior which would produce new host wires to already existing host wirings.

> Resolver impl is in need of extensive cleanup
> ---------------------------------------------
>
>                 Key: FELIX-5251
>                 URL: https://issues.apache.org/jira/browse/FELIX-5251
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>    Affects Versions: resolver-1.8.0
>         Environment: All
>            Reporter: Thomas Watson
>            Assignee: Thomas Watson
>
> The Resolver implementation has undergone a lot of changes since it was first contributed.  Over the coarse of development the code has deteriorated a bit.  This is not to blame the contributors to the codebase.  The codebase and overall problem is complicated and already hard enough to understand.
> I have been looking to implement some upcoming changes that are being proposed for the OSGi R7 specification.  Before I start that work I have been spending significant time scrubbing the resolver code and trying to make it a little more understandable.  Here are the main things I have done:
> 1) Create a common code path for dynamic resolution and regular resolution.  
> 2) Extract common code and greatly reduce the number of lines contained in complicated do/while loops.
> 3) Make proper use of the existing ResolveSession class to keep track of state during the resolution process.   This keeps the maintenance of state in one place.  The code had evolved into many separate options being passed around to methods, each maintaining some kind of state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)