[jira] [Commented] (FELIX-4417) Circular references detected but not resolved if one of the references in the cycle has optional cardinality
[ https://issues.apache.org/jira/browse/FELIX-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128189#comment-14128189 ] Enrique Ruiz (DiSiD Technologies S.L.) commented on FELIX-4417: --- David: I totally agree, I will check the service reference graph. Circular references detected but not resolved if one of the references in the cycle has optional cardinality Key: FELIX-4417 URL: https://issues.apache.org/jira/browse/FELIX-4417 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.8.2 Reporter: Victor Antonovich Attachments: CircularReferenceTest-trunk.patch, CircularReferenceTest.zip Looks like current Apache Felix SCR implementation doesn't conform fully to Declarative Services Specification, which says (http://www.osgi.org/download/r4v43/osgi.cmpn-4.3.0.pdf, 112.3.7): Circular references must be detected by SCR when it attempts to satisfy component configurations and SCR must fail to satisfy the references involved in the cycle and log an error message with the Log Service, if present. However, if one of the references in the cycle has optional cardinality SCR must break the cycle. The reference with the optional cardinality can be satisfied and bound to zero target services. Therefore the cycle is broken and the other references may be satisfied. In case of two components, A and B, where A is delayed with 1..1 static reference to B, and B is immediate with 0..n dynamic reference to A, Felix SCR should: 1) activate B with dynamic reference to A satisfied and bound to zero services 2) activate A with satisfied static reference to B 3) bind dynamic reference to B in component A But it seems current Felix SCR implementation can't handle this kind of circular dependency correctly and is failing with message Circular reference detected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4417) Circular references detected but not resolved if one of the references in the cycle has optional cardinality
[ https://issues.apache.org/jira/browse/FELIX-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128201#comment-14128201 ] Markus Kaufhold commented on FELIX-4417: David: Your comment is right, nevertheless the original complaint is still valid. However, if one of the references in the cycle has optional cardinality SCR must break the cycle. The reference with the optional cardinality can be satisfied and bound to zero target services. Therefore the cycle is broken and the other references may be satisfied. Felix SCR isn't compliant to that OSGi part. We do have the following use case, using that scheme: Component B is responsible for a certain functionality, and registers an interface b as a service that provides access to some information of that functionality. As the information of that functionality can change during runtime, component A also defines another interface c, which can be implemented and registered by anybody that is interested in those changes. Component B is then binding c as 0..n (optional). Component A is interested in the information of b, and needs to be informed about changes during runtime, thus A is then binding b unary (1..1) and providing c as a service. According OSGi chapter 112.3.7 this is a valid use case, to be supported by the SCR. With the current implementation the Felix SCR does not differentiate between mandatory and optional references within the cycle detection. From implementation point of view this is not easy to solve, as in the context of component A it is not known that component B is binding c in an optional way. Circular references detected but not resolved if one of the references in the cycle has optional cardinality Key: FELIX-4417 URL: https://issues.apache.org/jira/browse/FELIX-4417 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.8.2 Reporter: Victor Antonovich Attachments: CircularReferenceTest-trunk.patch, CircularReferenceTest.zip Looks like current Apache Felix SCR implementation doesn't conform fully to Declarative Services Specification, which says (http://www.osgi.org/download/r4v43/osgi.cmpn-4.3.0.pdf, 112.3.7): Circular references must be detected by SCR when it attempts to satisfy component configurations and SCR must fail to satisfy the references involved in the cycle and log an error message with the Log Service, if present. However, if one of the references in the cycle has optional cardinality SCR must break the cycle. The reference with the optional cardinality can be satisfied and bound to zero target services. Therefore the cycle is broken and the other references may be satisfied. In case of two components, A and B, where A is delayed with 1..1 static reference to B, and B is immediate with 0..n dynamic reference to A, Felix SCR should: 1) activate B with dynamic reference to A satisfied and bound to zero services 2) activate A with satisfied static reference to B 3) bind dynamic reference to B in component A But it seems current Felix SCR implementation can't handle this kind of circular dependency correctly and is failing with message Circular reference detected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FELIX-4417) Circular references detected but not resolved if one of the references in the cycle has optional cardinality
[ https://issues.apache.org/jira/browse/FELIX-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128201#comment-14128201 ] Markus Kaufhold edited comment on FELIX-4417 at 9/10/14 10:27 AM: -- David: Your comment is right, nevertheless the original complaint is still valid. However, if one of the references in the cycle has optional cardinality SCR must break the cycle. The reference with the optional cardinality can be satisfied and bound to zero target services. Therefore the cycle is broken and the other references may be satisfied. Felix SCR isn't compliant to that OSGi part. We do have the following use case, using that scheme: Component B is responsible for a certain functionality, and registers an interface b as a service that provides access to some information of that functionality. As the information of that functionality can change during runtime, component B also defines another interface c, which can be implemented and registered by anybody that is interested in those changes. Component B is then binding c as 0..n (optional). Component A is interested in the information of b, and needs to be informed about changes during runtime, thus A is then binding b unary (1..1) and providing c as a service. According OSGi chapter 112.3.7 this is a valid use case, to be supported by the SCR. With the current implementation the Felix SCR does not differentiate between mandatory and optional references within the cycle detection. From implementation point of view this is not easy to solve, as in the context of component A it is not known that component B is binding c in an optional way. was (Author: markuska): David: Your comment is right, nevertheless the original complaint is still valid. However, if one of the references in the cycle has optional cardinality SCR must break the cycle. The reference with the optional cardinality can be satisfied and bound to zero target services. Therefore the cycle is broken and the other references may be satisfied. Felix SCR isn't compliant to that OSGi part. We do have the following use case, using that scheme: Component B is responsible for a certain functionality, and registers an interface b as a service that provides access to some information of that functionality. As the information of that functionality can change during runtime, component A also defines another interface c, which can be implemented and registered by anybody that is interested in those changes. Component B is then binding c as 0..n (optional). Component A is interested in the information of b, and needs to be informed about changes during runtime, thus A is then binding b unary (1..1) and providing c as a service. According OSGi chapter 112.3.7 this is a valid use case, to be supported by the SCR. With the current implementation the Felix SCR does not differentiate between mandatory and optional references within the cycle detection. From implementation point of view this is not easy to solve, as in the context of component A it is not known that component B is binding c in an optional way. Circular references detected but not resolved if one of the references in the cycle has optional cardinality Key: FELIX-4417 URL: https://issues.apache.org/jira/browse/FELIX-4417 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.8.2 Reporter: Victor Antonovich Attachments: CircularReferenceTest-trunk.patch, CircularReferenceTest.zip Looks like current Apache Felix SCR implementation doesn't conform fully to Declarative Services Specification, which says (http://www.osgi.org/download/r4v43/osgi.cmpn-4.3.0.pdf, 112.3.7): Circular references must be detected by SCR when it attempts to satisfy component configurations and SCR must fail to satisfy the references involved in the cycle and log an error message with the Log Service, if present. However, if one of the references in the cycle has optional cardinality SCR must break the cycle. The reference with the optional cardinality can be satisfied and bound to zero target services. Therefore the cycle is broken and the other references may be satisfied. In case of two components, A and B, where A is delayed with 1..1 static reference to B, and B is immediate with 0..n dynamic reference to A, Felix SCR should: 1) activate B with dynamic reference to A satisfied and bound to zero services 2) activate A with satisfied static reference to B 3) bind dynamic reference to B in component A But it seems current Felix SCR implementation can't handle this kind of circular dependency correctly and is failing with message Circular reference
[jira] [Created] (FELIX-4637) Gogo can't cope without several commands with defined service.ranking
Guillaume Nodet created FELIX-4637: -- Summary: Gogo can't cope without several commands with defined service.ranking Key: FELIX-4637 URL: https://issues.apache.org/jira/browse/FELIX-4637 Project: Felix Issue Type: Bug Components: Gogo Runtime Reporter: Guillaume Nodet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4525) Refactor the Framework to use the Resolver module
[ https://issues.apache.org/jira/browse/FELIX-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128970#comment-14128970 ] Richard S. Hall commented on FELIX-4525: I looked at this briefly and it looks fairly reasonable. I think you can keep going forward with it. Admittedly, I didn't look into it in much depth, so I'll try to look at it some more to refresh my memory about the dynamic import stuff. One nit, you change BundleRevisionImpl.toString() to be a fairly long string...I didn't look in depth at where this was being used, but I want to think it was being used for diagnostic output, which could make things a little verbose if so. We might want to check. Refactor the Framework to use the Resolver module - Key: FELIX-4525 URL: https://issues.apache.org/jira/browse/FELIX-4525 Project: Felix Issue Type: Task Components: Framework Affects Versions: framework-4.4.0 Reporter: David Bosschaert Assignee: David Bosschaert Fix For: framework-4.6.0 Currently both the framework has a resolver implementation as well as the resolver module, which has a separate resolver implementation. The resolver module originates from the framework, but they are not the same any more. It would be good to refactor the framework to use the resolver implementation from the resolver module so that there is no code duplication any more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
