Please unsubscribe me from the mailing list.
Thanks & regards, PROMIT This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!> _____ From: [email protected] [mailto:[email protected]] On Behalf Of BJ Hargrave Sent: Tuesday, July 28, 2009 4:55 AM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Questions on DS Spec > 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 ? > > BTW: Felix DS currently deactivates C to bind s3 upon registration and > then reactivates C again. Likewise Felix DS implements option (c). > None of these are correct. The correct answer is that the C instance deactivated in (4) is discarded and that object is *never* used again by DS. Since s2 and s3 are present, the reference is still satisfied and a *new* C instance is created, bound to s2 and s3 and then activated. >From the DS spec: "Once the component configuration is deactivated, SCR must discard all ref- erences to the component instance and component context associated with the activation."
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
