[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=16665285#comment-16665285
]
Stefan Bischof edited comment on FELIX-5973 at 10/26/18 3:27 PM:
-
sorry for the bad description and thank you for the description.
in the resolveresult is the bundle *ds.resolve.capfora* but not *ds.resolve.a*
This is incorrect. *ds.resolve.capfora* is *only* required from *ds.resolve.a
.* But *ds.resolve.a* is not in the Result.
{code:java}
Result
ds.resolve.b
ds.resolve.cap
ds.resolve.capfora
ds.resolve.req
org.apache.felix.scr
{code}
was (Author: bisch...@jena.de):
sorry for the bad description.
in the resolveresult is the bundle *ds.resolve.capfora*
This is incorrect. *ds.resolve.capfora* is *only* required from *ds.resolve.a
.* But *ds.resolve.a* is not in the Result.
{code:java}
Result
ds.resolve.b
ds.resolve.cap
ds.resolve.capfora
ds.resolve.req
org.apache.felix.scr
{code}
> 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="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="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)
[jira] [Commented] (FELIX-5973) fix resolving issues
[
https://issues.apache.org/jira/browse/FELIX-5973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665285#comment-16665285
]
Stefan Bischof commented on FELIX-5973:
---
sorry for the bad description.
in the resolveresult is the bundle *ds.resolve.capfora*
This is incorrect. *ds.resolve.capfora* is *only* required from *ds.resolve.a
.* But *ds.resolve.a* is not in the Result.
{code:java}
Result
ds.resolve.b
ds.resolve.cap
ds.resolve.capfora
ds.resolve.req
org.apache.felix.scr
{code}
> 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="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="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)
[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="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="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)
[jira] [Commented] (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 commented on FELIX-5973:
--
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="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="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)
[jira] [Commented] (FELIX-5974) Prototype scope references are not released on deactivation
[ https://issues.apache.org/jira/browse/FELIX-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665103#comment-16665103 ] ASF GitHub Bot commented on FELIX-5974: --- GitHub user timothyjward opened a pull request: https://github.com/apache/felix/pull/159 Provide a refactoring to simplify prototype reference access This should also Fix FELIX-5974 Signed-off-by: Tim Ward You can merge this pull request into a Git repository by running: $ git pull https://github.com/timothyjward/felix FELIX-5974 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/159.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #159 commit 1a0973e08353bb0c4e959fb2a01b861c9cfcc39b Author: Tim Ward Date: 2018-10-26T12:20:11Z Provide a refactoring to simplify prototype reference access This should also Fix FELIX-5974 Signed-off-by: Tim Ward > Prototype scope references are not released on deactivation > --- > > Key: FELIX-5974 > URL: https://issues.apache.org/jira/browse/FELIX-5974 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.1.12 >Reporter: Timothy Ward >Priority: Major > Fix For: scr-2.1.14 > > > Having read the stack overflow question on [Stack > Overflow|https://stackoverflow.com/questions/52839641/osgi-ds-prototype-reference-not-released] > I was pretty certain that the user must be doing something wrong, but in > fact it seems as though SCR does a bad job of releasing Prototype scoped > references when a component is disposed. > I looked into the code, and it seems that there are a lot of conflicting > locations where prototype scope services are obtained and released. I propose > tidying this up so that the ComponentServiceObjects is *always* used > internally regardless of whether it is injected or not. This encapsulates all > the access in a single location so it is less likely that the objects will > leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] felix pull request #159: Provide a refactoring to simplify prototype referen...
GitHub user timothyjward opened a pull request: https://github.com/apache/felix/pull/159 Provide a refactoring to simplify prototype reference access This should also Fix FELIX-5974 Signed-off-by: Tim Ward You can merge this pull request into a Git repository by running: $ git pull https://github.com/timothyjward/felix FELIX-5974 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/159.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #159 commit 1a0973e08353bb0c4e959fb2a01b861c9cfcc39b Author: Tim Ward Date: 2018-10-26T12:20:11Z Provide a refactoring to simplify prototype reference access This should also Fix FELIX-5974 Signed-off-by: Tim Ward ---
[jira] [Created] (FELIX-5974) Prototype scope references are not released on deactivation
Timothy Ward created FELIX-5974: --- Summary: Prototype scope references are not released on deactivation Key: FELIX-5974 URL: https://issues.apache.org/jira/browse/FELIX-5974 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-2.1.12 Reporter: Timothy Ward Fix For: scr-2.1.14 Having read the stack overflow question on [Stack Overflow|https://stackoverflow.com/questions/52839641/osgi-ds-prototype-reference-not-released] I was pretty certain that the user must be doing something wrong, but in fact it seems as though SCR does a bad job of releasing Prototype scoped references when a component is disposed. I looked into the code, and it seems that there are a lot of conflicting locations where prototype scope services are obtained and released. I propose tidying this up so that the ComponentServiceObjects is *always* used internally regardless of whether it is injected or not. This encapsulates all the access in a single location so it is less likely that the objects will leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
