You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Arnoud Glimmerveen <ar...@glimmerveen.org> on 2019/07/13 19:51:06 UTC
SCR: Question on how component references translate to service
'request' to the service registry
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
Re: SCR: Question on how component references translate to service
'request' to the service registry
Posted by Arnoud Glimmerveen <ar...@glimmerveen.org>.
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 <tj...@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 <da...@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 <ar...@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 <da...@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 <
>> arnoud@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
>>>
>>
>>
Re: SCR: Question on how component references translate to service
'request' to the service registry
Posted by Thomas Watson <tj...@gmail.com>.
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 <da...@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 <ar...@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 <da...@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 <
> arnoud@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
> >
>
>
Re: SCR: Question on how component references translate to service
'request' to the service registry
Posted by Arnoud Glimmerveen <ar...@glimmerveen.org>.
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 <da...@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 <ar...@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 <da...@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 <ar...@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
>>
>
Re: SCR: Question on how component references translate to service
'request' to the service registry
Posted by David Jencks <da...@gmail.com>.
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 <ar...@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 <da...@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 <ar...@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
>
Re: SCR: Question on how component references translate to service
'request' to the service registry
Posted by Arnoud Glimmerveen <ar...@glimmerveen.org>.
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 <da...@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 <ar...@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
Re: SCR: Question on how component references translate to service 'request' to the service registry
Posted by David Jencks <da...@gmail.com>.
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 <ar...@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