On 7/27/09 12:13 PM, Felix Meschberger wrote:
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.
This is incorrect, then. Static takes what it can get at the time of
component activation, it should not be proactively stopping and
restarting the component to get it higher ranking services. The
component being re-started to take advantage of higher ranking services
should be left as a decision to the deployment agent.
Such behavior would be equivalent to the framework rewiring a bundle's
package dependency automatically every time a newer version of the
package came along, which wouldn't make much sense. The static policy is
similar to how we treat package dependencies, which are resolved on what
is available at the time and anything coming later doesn't impact it
unless the deployment agent refreshes.
-> richard
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
