Hi Ikuo Yamasaki schrieb: > If how the current DS impl of Equinox works is not a bug, > I agree with Stoyan. Otherwise, unfortunately I would way the current DS > impl of Equinox has a bug. > > I would like to know how other DS impl, felix, knopflerfish or others, > works. Do you know, Richard ?
Speaking for the Apache Felix implementation and referring to the initial questions: Q1: static, 0..n, no serviceA bound, a serviceA registered The component is deactivated, the service bound and the component reactivated. Q2: static, 1..n, one serviceA bound, another serviceA registered As above, the component is deactivated, the second serviceA is bound and the component is reactivated. Q3: static, 1..1, one serviceA bound, another serviceA with higher rank registered We replace the bound serviceA with the new serviceA by a deactivate, unbind, bind, activate cycle of the component. The reason is that the initially bound service has been selected as per the service ranking (section 112.3.2 introducing service ranking to define which service of multiple matching to bind in unary references. If we would not do that, we have inconsistent behaviour if the consuming component is started before or after the second higher ranking serviceA. Q4: as Q3, but dynamic reference Again, we replace the bound serviceA with the new serviceA on the same assumption (consistency). And of course consistency is also the reason to handle static and dynamic references the same. We actually had a bug report for this problem when we did not replace lower ranking services with higher ranking ones: FELIX-950 [1]. I think, that if service ranking is only respected for the inital service binding, it is close to useless because you never know in which order components are activated and services registered. Just my €0.02 of course and there may be other (better) reasons. Regards Felix [1] https://issues.apache.org/jira/browse/FELIX-950 > > ======= > Ikuo YAMASAKI > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
