Hi David, I have opened a Jira issue [1] for the behaviour described here on the mailing list.
My first thought was to somehow merge the className and target filter, but looking at the SCR codebase I ‘feel’ that it won't be so simple. Regards, Arnoud Glimmerveen [1] https://issues.apache.org/jira/browse/FELIX-6161 > On 14 Jul 2019, at 18:27, David Jencks <[email protected]> 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 <[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 >> >
