All of your mandatory references must be injected before activate is called. 
This is a happens-before guarantee, and has nothing to do with the order of 
reference injection, instead being a formal part of the DS component lifecycle. 
Optional references will not be injected before calling activate if they are 
not available at the time.

The threading issue that you may see with the example below is that your 
volatile fields change during the call to doSomethingWithXandY(); - you should 
always copy the fields into a local variable if you need to guarantee that you 
are calling the same service throughout the method.

Regards,

Tim

> On 2 Feb 2018, at 09:35, Thomas Driessen <thomas.driessen...@gmail.com> wrote:
> 
> Hi,
> 
> thanks for all those answers and sorry for my late response.
> 
> Maybe I have been a little bit too imprecise.
> The reason I asked, was that I found this article by Peter Kriens about an 
> AggregateState: http://aqute.biz/2017/04/24/aggregate-state.html 
> <http://aqute.biz/2017/04/24/aggregate-state.html>
> 
> I wrote such a service and only was wondering afterwards if this really works 
> all the times or if I just hit a lucky punch and it worked the few times I 
> tested it. Or if I got Peter's intentions completely wrong and did something 
> AggregateState was not meant for.
> 
> So what I do is writing a component as described in the article like this:
> 
> @Component
> public class MyComp{
>     
>     @Reference(target="(&(x.prop=x)(y.prop=y))")
>     private AggregateState state;
> 
>     @Reference(target="(x.prop=x)")
>     private volatile X x;
> 
>     @Reference(target="(y.prop=y)")
>     private volatile Y y;
> 
>     @Activate
>     private void activate(){
>         doSomethingWithXandY();
>     }
> 
> }
> 
> So even if my AggregateState is satisfied, which means that there are 
> fitting, activated services for X and Y, can I rest assured that X and Y are 
> injected BEFORE activate() is called? Because my understanding was that X and 
> Y might still be null and MyComp is nevertheless eligible for activation. 
> 
> Kind regards,
> Thomas
> 
> 
> 
> ------ Originalnachricht ------
> Von: "BJ Hargrave" <hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>>
> An: tim.w...@paremus.com <mailto:tim.w...@paremus.com>; 
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> Cc: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>; 
> thomas.driessen...@gmail.com <mailto:thomas.driessen...@gmail.com>
> Gesendet: 31.01.2018 15:40:53
> Betreff: Re: [osgi-dev] DS Reference injection order
> 
>> Tim correctly cites the spec regarding the order SCR must process the 
>> <reference> elements in the XML. Since you are using annotations, there is 
>> one more thing to know. The javadoc for the Reference annotation states:
>>  
>> In the generated Component Description for a component, the references must 
>> be ordered in ascending lexicographical order (using String.compareTo ) of 
>> the reference names. 
>> 
>>  
>> So you can control the order of the reference elements in the xml by the 
>> names of the references.
>>  
>> The order of processing reference can be useful if you are using method 
>> injection and a method needs to use a previously injected reference. But 
>> since you examples show field injection, your component cannot not really 
>> observe the order of injection.
>>  
>> With 'volatile' you have a dynamic reference which can be updated at any 
>> time, so there is no order with respect to other reference.
>>  
>> --
>> 
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>
>>  
>>  
>> ----- Original message -----
>> From: Tim Ward via osgi-dev <osgi-dev@mail.osgi.org 
>> <mailto:osgi-dev@mail.osgi.org>>
>> Sent by: osgi-dev-boun...@mail.osgi.org 
>> <mailto:osgi-dev-boun...@mail.osgi.org>
>> To: Thomas Driessen <thomas.driessen...@gmail.com 
>> <mailto:thomas.driessen...@gmail.com>>, OSGi Developer Mail List 
>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
>> Cc:
>> Subject: Re: [osgi-dev] DS Reference injection order
>> Date: Wed, Jan 31, 2018 6:43 AM
>>  
>> Firstly - why do you need to rely on this? It sounds like very fragile code 
>> to me and you should probably consider rewriting so that you don’t need to 
>> care. However...
>>  
>> Section 112.5.7 of the compendium says that:
>> 
>> When binding services, the references are processed in the order in which 
>> they are specified in the component description. That is, target services 
>> from the first specified reference are bound before services from the next 
>> specified reference.
>>  
>> A static optional service will not be set if it is not satisfied, or will if 
>> it is. A dynamic optional service will behave the same way, but it may be 
>> unset and reset many times afterwards on other threads. Dynamic services 
>> should always be treated with care, whether they are optional or not.
>>  
>> Tim
>>  
>>> 
>>> On 31 Jan 2018, at 10:50, Thomas Driessen via osgi-dev 
>>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
>>>  
>>> Hi,
>>>  
>>> I searched the compendium spec but didn't find what I was looking for.
>>>  
>>> If I have a DS with multiple references to other DS
>>>  
>>> @Component
>>> class Example1{
>>>  
>>>     @Reference
>>>     Example2 e2
>>>  
>>>     @Reference
>>>     Example3 e3
>>> }
>>>  
>>> in which order are the references injected? Is there even a deterministic 
>>> order?
>>>  
>>> In the above example both references are static/mandatory. What happens if 
>>> I have a static/mandatory and a dynamic/optional one like this:
>>>  
>>> @Component
>>> class Example1{
>>>  
>>>     @Reference
>>>     Example2 e2
>>>  
>>>     @Reference
>>>     volatile Example3 e3
>>> }
>>>  
>>> Kind regards,
>>> Thomas
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=P8DWwyvfdkJmQulD35LW62YOdKbDVw6eIWSALp1HIbI&s=U70U3kBVjtwoTlXKCafEOLUaXN8uM6uEth9KO1zjavY&e=>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=P8DWwyvfdkJmQulD35LW62YOdKbDVw6eIWSALp1HIbI&s=U70U3kBVjtwoTlXKCafEOLUaXN8uM6uEth9KO1zjavY&e=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=P8DWwyvfdkJmQulD35LW62YOdKbDVw6eIWSALp1HIbI&s=U70U3kBVjtwoTlXKCafEOLUaXN8uM6uEth9KO1zjavY&e=>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to