felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stijn de Witt <Stijn.deW...@planonsoftware.com>
Subject RE: Felix SCR service ordering
Date Mon, 04 Nov 2013 12:04:04 GMT
> 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:david_jencks@yahoo.com] 
Sent: zaterdag 2 november 2013 9:16
To: users@felix.apache.org
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 <Bruce.Jackson@myriadgroup.com> 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" <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


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

Mime
View raw message