[
https://issues.apache.org/jira/browse/FELIX-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13600031#comment-13600031
]
Richard S. Hall commented on FELIX-3962:
----------------------------------------
Technically, from this resolver's perspective, returning a resolved host
capability is invalid. However, if we want to patch it so that it filters it so
that it doesn't lead to strange errors, then we can do that.
> 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 WrappedResource 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 the code 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
