In this case you do not have such guarantee about injection. And it won’t be 
necessary since you could just make them mandatory references. 

You need to distinguish two things:

1) The existence of or the state of the system
2) Injection

If you have an optional dependence then all bets are off because there can 
always be a delay between the events. Only mandatory references give you any 
guarantee here. For example, to handle cyclic dependencies DS can delay 
injection of optional dependencies although the service is present. 

What you could do is to lookup the services through the component context, they 
should be there.

So what you can observe through the AggregateState service is not by definition 
observable through optional services. A bit like relativity theory.

Kind regards,

        Peter Kriens




> On 2 Feb 2018, at 10:35, Thomas Driessen via osgi-dev 
> <osgi-dev@mail.osgi.org> 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

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to