| Re: [osgi-users] Declarative Service Curiosity |
Yours and Dirks explanation makes sense and I suspected the same
thing.
From a Implementation perspective, this is logical behaviour. I'm not sure however if this is what any user would suspect. Thus, I will raise an issue for this and would like to discuss this on our next call.
It is possible that the ServiceRegistration for the immediate component happens before the activation of the immediate component. The DS spec does not require that an immediate component be activated before its service is registered. It only requires the immediate component to be activated once all dependencies are satisfied.
I do not see an error in the SCR implementation nor a problem in the DS spec. Without injection, you don't cause a happens-before relationship between the activation of the referenced (immediate) component and the activation of the referencing component. Since the referencing component does not actually cause the immediate component to be injected, the referencing component activation can proceed before the immediate component is activated. The activation of the 2 components is unordered.
I think the simple solution is to just use field or constructor injection in the referencing component to the referenced component. This will establish the desired ordering.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
From: osgi-users <osgi-users-bounces@xxxxxxxxxxx> on behalf of Jürgen Albert <j.albert@xxxxxxxxxxxxxxxxxx>
Sent: Friday, April 8, 2022 05:08
To: osgi-users@xxxxxxxxxxx <osgi-users@xxxxxxxxxxx>
Subject: [EXTERNAL] [osgi-users] Declarative Service CuriosityHi,
I have a bit of an odd Situation and I'm not sure if I have a faulty
expectation:
I have 2 Components:
@Component(immediate = true, property = Condition.CONDITION_ID + "=" +
CONDITION_EQUINOX_CONFIG)
public class EquinoxConfigInitializerImpl implements Condition {
@Activate
public void activate(ComponentContext ctx) {
// some code here
}
}
I have a second component that does require this Condition to be there
and to be activated. It does not need to be injected, so I reference it
only in the annotation.
@Component(immediate=true , reference = {
@Reference(name = "equinoxConfig", service = Condition.class,
policy=ReferencePolicy.STATIC,
cardinality=ReferenceCardinality.MANDATORY, target = "(" +
Condition.CONDITION_ID + "=" + CONDITION_EQUINOX_CONFIG + ")")
} )
public class Component2 { ... }
My expectation thus has been, that the EquinoxConfigInitializerImpl
would have been activated before Component2. For some reason this is not
the case and it is activated after Component2. I couldn't really find
something concrete in the Spec that lead me to a definitive answer.
Am I wrong, is this undefined or did I find a Bug in SCR (2.1.16)?
Regards,
Jürgen.
--
Jürgen Albert
CEO
Chair Eclipse OSGi Working Group Steering Committee
Data In Motion Consulting GmbH
Kahlaische Str. 4
07745 Jena
Mobil: +49 157-72521634
E-Mail: j.albert@xxxxxxxxxxxxxxx
Web: www.datainmotion.de
XING: https://www.xing.com/profile/Juergen_Albert5
LinkedIn: https://www.linkedin.com/in/juergen-albert-6a1796/
Rechtliches
Jena HBR 513025
_______________________________________________
osgi-users mailing list
osgi-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/osgi-users
_______________________________________________ osgi-users mailing list osgi-users@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/osgi-users
-- Jürgen Albert CEO Chair Eclipse OSGi Working Group Steering Committee Data In Motion Consulting GmbH Kahlaische Str. 4 07745 Jena Mobil: +49 157-72521634 E-Mail: j.albert@xxxxxxxxxxxxxxx Web: www.datainmotion.de XING: https://www.xing.com/profile/Juergen_Albert5 LinkedIn: https://www.linkedin.com/in/juergen-albert-6a1796/ Rechtliches Jena HBR 513025