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
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>
An: tim.w...@paremus.com; osgi-dev@mail.osgi.org
Cc: osgi-dev@mail.osgi.org; 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
----- Original message -----
From: Tim Ward via osgi-dev <osgi-dev@mail.osgi.org>
Sent by: osgi-dev-boun...@mail.osgi.org
To: Thomas Driessen <thomas.driessen...@gmail.com>, OSGi Developer
Mail List <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> 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
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
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
