You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by GLIMMERVEEN Arnoud <Ar...@nl.thalesgroup.com> on 2020/03/23 13:29:08 UTC
Resolving open issue FELIX-6161
Hi all,
Last July I opened an issue [1] regarding SCR's behaviour with respect to tracking services and how it prevents the use of 'Providing service on demand pattern' [2]. I also provided a patch that enables this pattern to be used in combination with Felix SCR.
There has been an exchange of comments on the issue, with respect to it still supporting the original use-case of the current approach to service tracking and whether or not the proposed change could possibly negatively affect the performance of SCR.
To my understanding the patch submitted still supports the original use-case. On the performance aspect, there is indeed the overhead of additional trackers in case you reference the same service multiple times, but I think there is also merit in simplifying the logic within SCR itself, by more relying on framework events, rather than doing target matching within SCR itself.
I would like to see if we can get a conclusion for this issue. Of course my preference would be to get the proposed changes merged into Felix SCR, but if the concerns remain I would like to see what can be done to mitigate these.
Best regards,
Arnoud Glimmerveen.
[1] https://issues.apache.org/jira/browse/FELIX-6161
[2] https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721
------------------------------------------------------------------------------------------------------------
Disclaimer:
If you are not the intended recipient of this email, please notify the sender and
delete it.
Any unauthorized copying, disclosure or distribution of this email or its
attachment(s) is forbidden.
Thales Nederland BV will not accept liability for any damage caused by this email or
its attachment(s).
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------
Re: Resolving open issue FELIX-6161
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks David,
I'll cut a SCR release this week to get all the other changes out. Then
we can have a look at FELIX-6161.
Regards
Carsten
On 12.04.2020 17:23, David Jencks wrote:
> I don’t think anyone should take my opinion as definitive, but when I (briefly) reviewed this some time ago I thought the proposed changes were fine. Since the spec apparently suggests that this “service on demand” scenario should be supported, I think this is a good idea.
>
> David Jencks
>
>> On Apr 12, 2020, at 3:07 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> Hi,
>>
>> I agree it would be good to get to a conclusion on this one in one way or the other.
>>
>> @Tom, @David J - WDYT?
>>
>> Regards
>> Carsten
>>
>> On 23.03.2020 14:29, GLIMMERVEEN Arnoud wrote:
>>> Hi all,
>>> Last July I opened an issue [1] regarding SCR's behaviour with respect to tracking services and how it prevents the use of 'Providing service on demand pattern' [2]. I also provided a patch that enables this pattern to be used in combination with Felix SCR.
>>> There has been an exchange of comments on the issue, with respect to it still supporting the original use-case of the current approach to service tracking and whether or not the proposed change could possibly negatively affect the performance of SCR.
>>> To my understanding the patch submitted still supports the original use-case. On the performance aspect, there is indeed the overhead of additional trackers in case you reference the same service multiple times, but I think there is also merit in simplifying the logic within SCR itself, by more relying on framework events, rather than doing target matching within SCR itself.
>>> I would like to see if we can get a conclusion for this issue. Of course my preference would be to get the proposed changes merged into Felix SCR, but if the concerns remain I would like to see what can be done to mitigate these.
>>> Best regards,
>>> Arnoud Glimmerveen.
>>> [1] https://issues.apache.org/jira/browse/FELIX-6161
>>> [2] https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721
>>> ------------------------------------------------------------------------------------------------------------
>>> Disclaimer:
>>> If you are not the intended recipient of this email, please notify the sender and
>>> delete it.
>>> Any unauthorized copying, disclosure or distribution of this email or its
>>> attachment(s) is forbidden.
>>> Thales Nederland BV will not accept liability for any damage caused by this email or
>>> its attachment(s).
>>> Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
>>> Commerce under number 06061578.
>>> ------------------------------------------------------------------------------------------------------------
>>
>> --
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Resolving open issue FELIX-6161
Posted by David Jencks <da...@gmail.com>.
I don’t think anyone should take my opinion as definitive, but when I (briefly) reviewed this some time ago I thought the proposed changes were fine. Since the spec apparently suggests that this “service on demand” scenario should be supported, I think this is a good idea.
David Jencks
> On Apr 12, 2020, at 3:07 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi,
>
> I agree it would be good to get to a conclusion on this one in one way or the other.
>
> @Tom, @David J - WDYT?
>
> Regards
> Carsten
>
> On 23.03.2020 14:29, GLIMMERVEEN Arnoud wrote:
>> Hi all,
>> Last July I opened an issue [1] regarding SCR's behaviour with respect to tracking services and how it prevents the use of 'Providing service on demand pattern' [2]. I also provided a patch that enables this pattern to be used in combination with Felix SCR.
>> There has been an exchange of comments on the issue, with respect to it still supporting the original use-case of the current approach to service tracking and whether or not the proposed change could possibly negatively affect the performance of SCR.
>> To my understanding the patch submitted still supports the original use-case. On the performance aspect, there is indeed the overhead of additional trackers in case you reference the same service multiple times, but I think there is also merit in simplifying the logic within SCR itself, by more relying on framework events, rather than doing target matching within SCR itself.
>> I would like to see if we can get a conclusion for this issue. Of course my preference would be to get the proposed changes merged into Felix SCR, but if the concerns remain I would like to see what can be done to mitigate these.
>> Best regards,
>> Arnoud Glimmerveen.
>> [1] https://issues.apache.org/jira/browse/FELIX-6161
>> [2] https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721
>> ------------------------------------------------------------------------------------------------------------
>> Disclaimer:
>> If you are not the intended recipient of this email, please notify the sender and
>> delete it.
>> Any unauthorized copying, disclosure or distribution of this email or its
>> attachment(s) is forbidden.
>> Thales Nederland BV will not accept liability for any damage caused by this email or
>> its attachment(s).
>> Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
>> Commerce under number 06061578.
>> ------------------------------------------------------------------------------------------------------------
>
> --
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Resolving open issue FELIX-6161
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
I agree it would be good to get to a conclusion on this one in one way
or the other.
@Tom, @David J - WDYT?
Regards
Carsten
On 23.03.2020 14:29, GLIMMERVEEN Arnoud wrote:
> Hi all,
>
> Last July I opened an issue [1] regarding SCR's behaviour with respect to tracking services and how it prevents the use of 'Providing service on demand pattern' [2]. I also provided a patch that enables this pattern to be used in combination with Felix SCR.
>
> There has been an exchange of comments on the issue, with respect to it still supporting the original use-case of the current approach to service tracking and whether or not the proposed change could possibly negatively affect the performance of SCR.
> To my understanding the patch submitted still supports the original use-case. On the performance aspect, there is indeed the overhead of additional trackers in case you reference the same service multiple times, but I think there is also merit in simplifying the logic within SCR itself, by more relying on framework events, rather than doing target matching within SCR itself.
>
> I would like to see if we can get a conclusion for this issue. Of course my preference would be to get the proposed changes merged into Felix SCR, but if the concerns remain I would like to see what can be done to mitigate these.
>
> Best regards,
>
> Arnoud Glimmerveen.
>
> [1] https://issues.apache.org/jira/browse/FELIX-6161
> [2] https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721
>
>
> ------------------------------------------------------------------------------------------------------------
> Disclaimer:
>
> If you are not the intended recipient of this email, please notify the sender and
> delete it.
> Any unauthorized copying, disclosure or distribution of this email or its
> attachment(s) is forbidden.
> Thales Nederland BV will not accept liability for any damage caused by this email or
> its attachment(s).
> Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
> Commerce under number 06061578.
> ------------------------------------------------------------------------------------------------------------
>
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org