You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Thomas Watson (JIRA)" <ji...@apache.org> on 2018/10/26 12:58:00 UTC

[jira] [Comment Edited] (FELIX-5973) fix resolving issues

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

Thomas Watson edited comment on FELIX-5973 at 10/26/18 12:57 PM:
-----------------------------------------------------------------

I'll admit I have not looked at the recreation steps you have which could clear up my questions ...

I'm having a hard time following the description of the scenario though.  Is the result incorrect or invalid?  Or is it that it contains more resources than you expect in the resolution result?  With {{cardinality:=multiple}} the resolver doesn't control what other resources get pulled into the resolve operation.  That is up to the resolve context.  The resolver will ask the resolve context for the capabilities that match the requirement with {{cardinality:=multiple}} and the pull in every resource that provides a matching capability.  The resolver's job is to try and wire as many of the capabilities as possible to the requirement with {{cardinality:=multiple}}.  It is up to the resolve context to come up with a policy on what capabilities it returns to the resolver if it wants to limit what gets pulled into the resolve operation.


was (Author: tjwatson):
I'll admit I have not looked at the recreation steps you have which could clear up my questions ...

I'm having a hard time following the description of the scenario though.  Is the result incorrect or invalid?  Or is it that it contains more resources than you expect in the resolution result?  With `cardinality:=multiple` the resolver doesn't control what other resources get pulled into the resolve operation.  That is up to the resolve context.  The resolver will ask the resolve context for the capabilities that match the requirement with `cardinality:=multiple` and the pull in every resource that provides a matching capability.  The resolver's job is to try and wire as many of the capabilities as possible to the requirement with `cardinality:=multiple`.  It is up to the resolve context to come up with a policy on what capabilities it returns to the resolver if it wants to limit what gets pulled into the resolve operation.

> fix resolving issues
> --------------------
>
>                 Key: FELIX-5973
>                 URL: https://issues.apache.org/jira/browse/FELIX-5973
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>            Reporter: Stefan Bischof
>            Priority: Major
>
>  
> *Description*
> 1. Felix tries to resolve other bundles, even when the bundle has the capability for the requirement by its own
> 2. Felix resolves bundles, which are only required by bundles that aren't in the resolve result
>  
>  *Example:* [https://github.com/stbischof/ds.resolve]
>  
> try to resolve {{bundle req}}
>  * {{bundle req}} has the requirement {{namespace="ns",name="name"}}
> so we look for the same capability {{namespace="ns",name="name"}}
>  * bundle cap has the capability {{namespace="ns",name="name"}}
>  * but {{bundle cap}} has also a Requirement {{osgi.service;filter:="(objectClass=java.lang.Readable)";effective:=active;cardinality:=multiple}}.
>  * this could be providet by itsselve {{osgi.service;objectClass:List<String>="java.lang.Readable"}} (target property of @Reference is not processed)
> h3. Issues:
>  * it resolves {{bundle capfora}} which provides a capability that is required by {{bundle a}} -> provides also the capability that is required from {{bundle cap}} ( {{osgi.service;objectClass:List<String>="java.lang.Readable"}}).
>  * But in this case {{bundle a}} is not in the resolveresult
>  * bundle b is also resolved. (not needet, cap has the needet capability by its own)
>  
> *Reproduce:*
> h3. bndtools/eclipse
> push the resolve button at ds.resolve/resolveActive.bndrun
> h3. commands
>  
> {code:java}
> git clone https://github.com/stbischof/ds.resolve.git
> cd ds.resolve
> java -jar biz.aQute.bnd-4.1.0.jar clean
> java -jar biz.aQute.bnd-4.1.0.jar _par
> java -jar biz.aQute.bnd-4.1.0.jar resolve resolve --write ds.resolve/resolveActive.bndrun
> git diff
> {code}
>  
>  
> results:
> {{+-runbundles: \ + ds.resolve.b;version=snapshot,\ + ds.resolve.cap;version=snapshot,\ + ds.resolve.capfora;version=snapshot,\ + ds.resolve.req;version=snapshot,\ + org.apache.felix.scr;version='[2.1.0,2.1.1)'}}
> h2.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)