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 <[email protected]> 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 > [email protected]
