Hi, Richard S. Hall schrieb: > > > 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.
That analogy makes perfect sense, so I come to agree, that the Felix DS implementation with respect to Q3 is wrong (and I will be going to fix this). >> >> Q4: as Q3, but dynamic reference How about this one ? Has the CPEG decided to state something for dynamic bindings, too ? I terms of consistency, I would assume, that regardless of whether a service is bound statically or dynamically, it should not never be replaced (unless the bound service is unregistered or the target property is modified such that service binding changes). WDYT ? Regards and Thanks Felix >> >> 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 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
