[
https://issues.apache.org/jira/browse/FELIX-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Watson updated FELIX-3962:
---------------------------------
Description:
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.
was:
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.
> 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
