felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Jackson <Bruce.Jack...@myriadgroup.com>
Subject Re: Felix SCR service ordering
Date Sat, 02 Nov 2013 00:47:10 GMT
The more I think about this problem, the more important it becomes. While
it is possible in ‘regular’ OSGi to get all of the ServiceReference
objects for a given class, and call getProperty(Constants.SERVICE_RANKING)
and sort the return list by this property, there doesn’t appear to be a
similar pattern available in DS.

All I can do with a reference is locate the services, but this gives me an
unordered list with no access to the service properties and no obvious way
to locate the ServiceReference that is associated with the service.

On 01/11/2013 20:58, "Bruce Jackson" <Bruce.Jackson@myriadgroup.com> wrote:

>I’m using 1.6.2. The quote refers to the case where there are multiple
>services bound to a reference, and indeed the source for SRC does order
>the (multiple) services when the caller invokes
>ComponentContext.locateService().
>
>My question is that given this is the case when I call that method and
>there are multiple providers (as in my example) why would this not also be
>true in the case of ComponentContext.locateServices() ?
>
>There are many cases where this is desirable, and frankly I can’t see a
>downside to it. In my case (the example code is a simple but
>illustrative), it would allow me to chain the Ifoo providers
>automatically.
>
>Thanks
>
>Bruce
>
>On 01/11/2013 20:32, "David Jencks" <david_jencks@yahoo.com> wrote:
>
>>?? Your quote refers to unary references, not multiple.  I still don't
>>see anything in the spec that suggests any order for binding or the
>>return value of locateServices.  However...
>>
>>Which version of DS are you using?  Looking at trunk (same as the 1.8.0
>>release candidate) the services should be ordered by the ServiceReference
>>ordering.
>>
>>thanks
>>david jencks
>>
>>On Nov 1, 2013, at 12:00 PM, Bruce Jackson
>><Bruce.Jackson@myriadgroup.com> wrote:
>>
>>> While this isn’t explicit in the spec, there are several reasons why
>>>I’d
>>> expect this implied behaviour:
>>>
>>> 1. clearly a sorting algorithm is in place to sort by service ranking
>>>when
>>> calling the locateService() method
>>> 2. the same thing is true for ServiceTracker.getServiceReference()
>>>
>>> I don’t see where in the spec the 1..1 or 1..n has any relation to
>>>service
>>> ranking. The spec states that dynamic multiple references should be
>>> handled in the same way:
>>>
>>> "If the reference has a unary
>>> cardinality and there is more than one target service for the
>>>reference,
>>> then
>>> the bound service must be the target service with the highest service
>>>rank-
>>> ing as specified by the service.ranking property. If there are multiple
>>> target
>>> services with the same service ranking, then the bound service must be
>>>the
>>> target service with the highest service ranking and the lowest service
>>>ID
>>> as
>>> specified by the service.id property."
>>>
>>>
>>>
>>>
>>>
>>> So, if the call to locateService must do reference ordering by
>>> service.ranking, why not use the same ranking for locateServices?
>>>
>>> Thanks
>>>
>>> Bruce
>>>
>>>
>>> On 01/11/2013 16:52, "David Jencks" <david_jencks@yahoo.com> wrote:
>>>
>>>> Which part of the spec are you looking at that makes you expect a
>>>> particular order?
>>>>
>>>> If you have a 1..1 reference and both IFoos are registered when
>>>> FooConsumer is activated then you'll get the one with the highest
>>>>service
>>>> ranking.
>>>>
>>>> For a dynamic multiple reference it doesn't really make sense to
>>>>expect a
>>>> particular binding order since new services with any service rank may
>>>>be
>>>> registered in another thread while the "original" set of services is
>>>> being bound, so there will be at least two threads binding services.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Nov 1, 2013, at 6:35 AM, Bruce Jackson
>>>><Bruce.Jackson@myriadgroup.com>
>>>> wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> I have 2 components, Afoo and Bfoo that both implement the same
>>>>> interface
>>>>> Ifoo. The component xml for both is shown below:
>>>>>
>>>>> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
>>>>> immediate="true" name="AFoo">
>>>>>       <implementation class="com.myriadgroup.scrtest.AFoo"/>
>>>>>       <service>
>>>>>               <provide interface="com.myriadgroup.scrtest.IFoo"/>
>>>>>       </service>
>>>>>       <property name="service.ranking" type="Integer" value="1"/>
>>>>> </scr:component>
>>>>>
>>>>>
>>>>> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
>>>>> immediate="true" name="BFoo">
>>>>>       <implementation class="com.myriadgroup.scrtest.BFoo"/>
>>>>>       <service>
>>>>>               <provide interface="com.myriadgroup.scrtest.IFoo"/>
>>>>>       </service>
>>>>>       <property name="service.ranking" type="Integer" value="2"/>
>>>>> </scr:component>
>>>>>
>>>>>
>>>>> I have another component FooConsumer that looks up Ifoo instances
>>>>> through
>>>>> the reference name Foo:
>>>>>
>>>>> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
>>>>> name="com.myriadgroup.scrtest">
>>>>>       <implementation class="com.myriadgroup.scrtest.FooConsumer"/>
>>>>>       <reference cardinality="1..n"
>>>>> interface="com.myriadgroup.scrtest.IFoo"
>>>>> name="IFoo" policy="static"/>
>>>>> </scr:component>
>>>>>
>>>>>
>>>>> From what I see in the spec, I would expect the Ifoo instances to be
>>>>> ordered in terms of the service.ranking when I call
>>>>> componentContext.locateServices(³Ifoo²). However, this is not the
>>>>>case:
>>>>> the ordering of the returned component array is entirely arbitrary.
>>>>>
>>>>> Can anyone shed any light on this behaviour?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Bruce
>>>>>
>>>>> *** DISCLAIMER ***
>>>>>
>>>>> This message, including attachments, is intended solely for the
>>>>> addressee indicated in this message and is strictly confidential or
>>>>> otherwise privileged. If you are not the intended recipient (or
>>>>> responsible for delivery of the message to such person) : - (1)
>>>>>please
>>>>> immediately (i) notify the sender by reply email and (ii) delete this
>>>>> message and attachments, - (2) any use, copy or dissemination of this
>>>>> transmission is strictly prohibited. If you or your employer does not
>>>>> consent to Internet email messages of this kind, please advise Myriad
>>>>> Group AG by reply e-mail immediately. Opinions, conclusions and other
>>>>> information expressed in this message are not given or endorsed by
>>>>> Myriad Group AG unless otherwise indicated by an authorized
>>>>> representative independent of this message.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> *** DISCLAIMER ***
>>>
>>> This message, including attachments, is intended solely for the
>>>addressee indicated in this message and is strictly confidential or
>>>otherwise privileged. If you are not the intended recipient (or
>>>responsible for delivery of the message to such person) : - (1) please
>>>immediately (i) notify the sender by reply email and (ii) delete this
>>>message and attachments, - (2) any use, copy or dissemination of this
>>>transmission is strictly prohibited. If you or your employer does not
>>>consent to Internet email messages of this kind, please advise Myriad
>>>Group AG by reply e-mail immediately. Opinions, conclusions and other
>>>information expressed in this message are not given or endorsed by
>>>Myriad Group AG unless otherwise indicated by an authorized
>>>representative independent of this message.
>>> 龜菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉菉契?F??V?7V'67&?R??R蘆
>>>?뽂?W6W'2?V?7V'67&?T?fV?뾺????6냃捻&p圭f?"??FF뾈뽺???6寢???G2??R蘆
>>>?뽂?W6W'2?냌???fV?뾺????6냃捻&p?
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>For additional commands, e-mail: users-help@felix.apache.org
>>
>
>*** DISCLAIMER ***
>
>This message, including attachments, is intended solely for the addressee
>indicated in this message and is strictly confidential or otherwise
>privileged. If you are not the intended recipient (or responsible for
>delivery of the message to such person) : - (1) please immediately (i)
>notify the sender by reply email and (ii) delete this message and
>attachments, - (2) any use, copy or dissemination of this transmission is
>strictly prohibited. If you or your employer does not consent to Internet
>email messages of this kind, please advise Myriad Group AG by reply
>e-mail immediately. Opinions, conclusions and other information expressed
>in this message are not given or endorsed by Myriad Group AG unless
>otherwise indicated by an authorized representative independent of this
>message.

*** DISCLAIMER ***

This message, including attachments, is intended solely for the addressee indicated in this
message and is strictly confidential or otherwise privileged. If you are not the intended
recipient (or responsible for delivery of the message to such person) : - (1) please immediately
(i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any
use, copy or dissemination of this transmission is strictly prohibited. If you or your employer
does not consent to Internet email messages of this kind, please advise Myriad Group AG by
reply e-mail immediately. Opinions, conclusions and other information expressed in this message
are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative
independent of this message.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Mime
View raw message