To add to what David was referring to > For a multiple cardinality reference, you can keep track of all the service > references and order them yourself.
You can use the approach as illustrated in [1]. The approach would be 1. Have a multiple reference 2. Implement bind and unbind methods and wrap the config map using ServiceUtil [2] to a comparable 3. Store the service instance against that comparable (#2) in a ConcurrentSkipListMap. That would keep the sorting order 4. Access the instance from the map [1] https://gist.github.com/chetanmeh/3918574 [2] https://github.com/apache/sling/blob/trunk/bundles/commons/osgi/src/main/java/org/apache/sling/commons/osgi/ServiceUtil.java Chetan Mehrotra On Mon, Nov 4, 2013 at 5:34 PM, Stijn de Witt <[email protected]> wrote: >> The spec says which one it is, not that the algorithm is picking the first >> element in an ordered collection. > > Yes, and the spec describes in what order the services are selected. The one > with the highest ranking is selected and if there are multiple with same > ranking, the one with the lowest ID. So in effect this describes a way of > sorting the services (ORDER BY service.ranking asc, ID desc), then picking > the first one. > >> Finally, I'm not sure why you are still asking for this after I told you I >> think it already works the way you want in trunk > > My guess is he wants to program to the spec, not to a specfic implementation > that might change. So the fact that Felix is doing it this way already is > great, but there is no guarantee it will not change suddenly in the future... > Probably he should contact some OSGi mailing list and not the Felix mailing > list? > > -Stijn > > > -----Original Message----- > From: David Jencks [mailto:[email protected]] > Sent: zaterdag 2 november 2013 9:16 > To: [email protected] > Subject: Re: Felix SCR service ordering > > I'm losing you here. If it's a unary reference, at most one service is > bound, no matter how many satisfy the filter for the reference. Your spec > quote is about unary references. There's at most one bound service. The > spec says which one it is, not that the algorithm is picking the first > element in an ordered collection. > > I've never seen anyone use a pure lookup strategy. All the DS components > I've seen use the event strategy with bind and unbind methods. You can have > a bind method that takes a service reference. For a multiple cardinality > reference, you can keep track of all the service references and order them > yourself. > > Finally, I'm not sure why you are still asking for this after I told you I > think it already works the way you want in trunk and the 1.8.0 release > candidate. Could you check before telling us how much this needs to be > implemented? > > thanks > david jencks > > On Nov 1, 2013, at 5:47 PM, Bruce Jackson <[email protected]> > wrote: > >> 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" <[email protected]> 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" <[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. >> >> *** 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
