I have attached a.patch to issue FELIX-6161 that solves the issue in my case, and hopefully does not break the use case [1] that prompted David to implement the ServiceListener in the way it was implemented.
Any feedback on and testing of the patch is very much appreciated! Arnoud. [1] https://issues.apache.org/jira/browse/FELIX-4964 > On 15 Jul 2019, at 15:34, Thomas Watson <tjw...@gmail.com> wrote: > > My guess is the current code makes it easier to deal with cases where the > service properties no longer match the specific target filter for the > reference. There was a new event added to org.osgi.framework package > version 1.5 that was supposed to help deal with this: > > https://osgi.org/specification/osgi.core/7.0.0/framework.api.html#org.osgi.framework.ServiceEvent.MODIFIED_ENDMATCH > > Not sure if the SCR implementation ever tried to adopt the use of this > "new" event. > > The other thing to consider is the number of listeners registered with the > framework. Perhaps it was shown that increasing the number of listeners to > be 1-1 with target filters increased the overhead in some measurable way. > Although it would seem that the internal logic of filter matching in SCR > would be nearly identical to the matching done by the framework. > > Tom. > > On Sun, Jul 14, 2019 at 11:27 AM David Jencks <david.a.jen...@gmail.com> > wrote: > >> Hi Arnold, >> >> I agree your scenario fits into “providing services on demand”; I wasn’t >> aware of this spec section, and never thought of trying this. I’m still >> not comfortable with the idea although it seems like something I might be >> enthusiastically promoting if I had thought of it! >> >> Since the spec mentions this possibility, it would be nice if Felix SCR >> could support it. How important do others think this is? So far I haven’t >> remembered the details of the problem I was solving by filtering in SCR >> rather than in the service listener. >> >> My first idea to solve this problem is to register a factory configuration >> for each target filter; I think this is the same as what you propose. I >> wonder if you could put the code to do this in a ConfigurationListener >> registered with config admin; of course this assumes that the component >> with the target filter is configured through config admin. >> >> Hope this helps, and thanks for raising this interesting problem. >> David Jencks >> >>> On Jul 14, 2019, at 8:28 AM, Arnoud Glimmerveen <arn...@glimmerveen.org> >> wrote: >>> >>> Hi David, >>> >>> Thanks for your response and providing some background on the behaviour >> of Felix SCR with respect to handling references. I am wondering what you >> mean with your remark on mixing logical levels. I thought that my use of >> the Service ListenerHook would fall within the parameters of one of the >> usage scenarios described in section 55.3.2 (Providing a Service on Demand) >> [1], or do you see (other) concerns in my intended use of a Service >> ListenerHook? >>> >>> A different angle I see is to use a Managed Configuration Factory to >> describe each instance of the ’ServiceClass’ (with its distinguishing >> properties) in a Configuration object and have Felix SCR create service >> instances from them. There would be some duplication in this approach, as >> (some) properties would need to be both in the Configuration and in the >> target filter, but I guess this would work right? >>> >>> Best regards, >>> >>> Arnoud Glimmerveen >>> >>> [1] >> https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721 >>> >>>> On 13 Jul 2019, at 23:14, David Jencks <david.a.jen...@gmail.com> >> wrote: >>>> >>>> I certainly intended the behavior when I implemented it. I don’t >> remember the details but I think there is a problem receiving multiple >> service events for the same service for different references in the same >> bundle so I was forced into it. >>>> >>>> I think your use of service listener hooks is peculiar and is mixing >> logical levels. Even if you can get it to work I’d advise looking at your >> problem from a different angle to find a different solution. >>>> >>>> David Jencks >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 13, 2019, at 12:51 PM, Arnoud Glimmerveen < >> arn...@glimmerveen.org> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I am experimenting with OSGi Framework’ s Service ListenerHook to >> detect the need for a particular service and based on that need register a >> service that matches that need. An important aspect for my ListenerHook >> implementation is the ability to extract properties from the service need, >> that are then used to initialise a matching service. I’ll try to explain >> using an example: >>>>> >>>>> In my ListenerHook I expect to be notified of a service need as >> follows: >>>>> (&(objectClass=ServiceClass)(some.property=5)) >>>>> >>>>> Which would allow the ListenerHook to register a service with that >> property, thus providing a match of the requested service. >>>>> >>>>> This appears to work fine when the ‘requesting code’ is either using >> standard ServiceTracker or Felix’ DependencyManager. However when I have >> Declarative Services based code requesting the service as follows: >>>>> >>>>> @Reference(target = “(some.property=5)”) >>>>> ServiceClass service; >>>>> >>>>> The ListenerHook is unable to construct a matching service, as it only >> sees a service need for: >>>>> >>>>> (objectClass=ServiceClass) >>>>> >>>>> And the additional criterion from the target filter is not visible to >> the ListenerHook. >>>>> >>>>> I did some debugging and found that Felix SCR 2.1.16 registers a >> ServiceListener only for the className of a reference it needs to track. >> The target filter of the reference (if present) is matched within that >> ServiceListener and matches are tracked from then on. This behaviour >> unfortunately prevents my ListenerHook to see the ‘complete picture’ of >> what is needed and is not able to register a matching service. >>>>> >>>>> My question is: is the behaviour of SCR that I observed correct and >> desired, or have I stumbled on an issue in SCR? >>>>> >>>>> Any thoughts and/or insights are greatly appreciated! >>>>> >>>>> Best regards, >>>>> >>>>> Arnoud Glimmerveen >>> >> >>
