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

Reply via email to