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.
