Thomas Watson created FELIX-3962:
------------------------------------

             Summary: Resolver does not handle it well if the ResolveContext 
hands back hosts capabilities that are already resolved
                 Key: FELIX-3962
                 URL: https://issues.apache.org/jira/browse/FELIX-3962
             Project: Felix
          Issue Type: Bug
          Components: Resolver
            Reporter: Thomas Watson


I was running into some very strange uses constraint violations if my resolve 
context handed back host capabilities from resources that already have wirings 
(already resolved).  It is hard to pin point all the issues, but the end result 
was that when checking for consistencies I found the compare being done between 
WrappedCapability and the raw Capability and failing.  I think this was 
happening because of some inconsistencies for when a WrappedResource is created.

I easily worked around the issue in my ResolveContext implementation by not 
returning host capabilities for already resolved resources.  But I think the 
resolver impl should be more robust if this happens and weed out the host 
capabilities from resolved hosts if the resolver does not support attaching 
fragments to already resolved hosts.

I also would like to understand if the intention of the code is to only create 
WrappedResource objects for resources that have no wiring.  I know 
WrappedRequirement and WrappedCapability objects can get created for already 
resolved resources that have reqs and caps from attached fragments, but my 
understanding is that WrappedCapability objects are only to be created for 
resources that are unresolved (no wirings).  If not then there are a whole 
bunch of calls to ResolveContext.getWirings().get(...) that we need to check 
because currently it will pass WrappedResource objects to this.  That probably 
is not correct anyway, but it is dead wrong if the resource being wrapped 
really has wirings according to the ResolveContext.

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

Reply via email to