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" <[email protected]> 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 ><[email protected]> 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" <[email protected]> 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 >>><[email protected]> >>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> *** 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: [email protected] >For additional commands, e-mail: [email protected] > *** 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.
