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