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