On 7/27/09 3:07 PM, Felix Meschberger wrote:
Hi,
Richard S. Hall schrieb:
On 7/27/09 2:30 PM, Felix Meschberger wrote:
Hi,
Richard S. Hall schrieb:
To be clear, any additions with static policy should be ignored, not
just 1..1. For example, static 0..n would not see newly arriving
services after the component was activated, no matter if it was started
with 0 or n services at the time of activation. The only changes that
cannot be ignored, obviously, are the removal of used services.
Hmm. Interesting. Now, this has confusing consequences.
Consider the following case.
(1) Two Services serviceA registered (call it s1 and s2)
(2) Component C with statically bound serviceA reference with
0..n is activated:
-> Services s1 and s2 are bound
(3) serviceA type service s3 is registered but *not* bound to
Component C
(4) serviceA type service s1 is unregistered
-> Component C has to be deactivated to unbind s1
Is step (4) correct ? I assume, yes.
Yes.
But, what now ?
(a) C remains deactivated
(b) C is activated again with just s2 bound
(c) s2 remains bound, s3 is newly bound and C is activated
Which of these options is the intended behaviour ?
As I mentioned in another message, the component can be reactivated
immediately if replacements are available and it should take into
account everything that is available at that time, just like it does the
very first time it activates the component.
This would make the answer (c), sort of. I am not sure what you mean by
"s2 remains bound". When any component deactivates, it is unbound from
all services, since it is no longer active. So, there are bindings held
for an inactive component. All services are unbound. If the component
gets activated again, then the services are rebound.
That's what I meant.
Components with static policies are not supposed to see changes to those
dependencies. So, each time it activates, it should be safe for it to
assume it has received bindings for each static service in advance and
when it deactivates it should see unbindings for each service. If you
don't do this, then it somehow has to know that it had previously seen
services when it was active for which it won't receiving binding
callbacks. That doesn't make sense.
BTW: Felix DS currently deactivates C to bind s3 upon registration and
then reactivates C again. Likewise Felix DS implements option (c).
Well, again, it depends on what you mean precisely, but rebinding with
replacements is correct, but not unbinding is incorrect.
Ok, I think Felix DS is incorrect to reactivate the Component
immediately upon registration of serviceA s3.
But upon reactivation due to unbinding serviceA s1, the new serviceA s3
will be bound along with the still existing serviceA s2. (this would be
option (c) (clearly unbinding after decactivation and binding before
activation).
Yes, then it sounds like we are on the same page...
-> richard
Regards
Felix
-> richard
Regards
Felix
-> richard
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
------------------------------------------------------------------------
_______________________________________________
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
