Hi all, In today's CPEG F2F in Dublin, CPEG agreed that
https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1392 ---- BJ wrote: The component should not be deactivated. The Equinox DS impl is wrong. Since the set of bound service is still a subset of the set of target services, the component reference does not become unsatisfied and thus the component should not be deactivated. ---- I thank BJ and Stoyan for helping me to understand DS spec. Best regards, ======= Ikuo YAMASAKI On Mon, 27 Jul 2009 23:44:19 +0900 Ikuo Yamasaki <[email protected]> wrote: Ikuo> Hi Stoyan Ikuo> Ikuo> On Mon, 27 Jul 2009 11:10:37 +0300 Ikuo> Stoyan Boshev <[email protected]> wrote: Ikuo> Ikuo> Stoyan> Ikuo> Stoyan> BJ Hargrave wrote: Ikuo> Stoyan> > > BJ> > Could you tell me which descriptions in the spec address the Ikuo> Stoyan> > use of Ikuo> Stoyan> > > BJ> > static policy with Ikuo> Stoyan> > > BJ> > multiple cardinality in order to answer Q1 and Q2 ? Ikuo> Stoyan> > > BJ> Ikuo> Stoyan> > > BJ> See 112.5.7: "When a component configuration's reference is Ikuo> Stoyan> > satisfied, Ikuo> Stoyan> > > BJ> there is a set of Ikuo> Stoyan> > > BJ> zero or more target services for that reference. When the component Ikuo> Stoyan> > > BJ> config- Ikuo> Stoyan> > > BJ> uration is activated, a subset of the target services for each Ikuo> Stoyan> > reference Ikuo> Stoyan> > > BJ> are Ikuo> Stoyan> > > BJ> bound to the component configuration. The subset is chosen by the Ikuo> Stoyan> > cardi- Ikuo> Stoyan> > > BJ> nality of the reference. See Reference Cardinality on page306." Ikuo> Stoyan> > > Ikuo> Stoyan> > > Although I understand the underlieing idea, Ikuo> Stoyan> > > I don't think I am convinced completely regarding the description Ikuo> Stoyan> > ofthe spec. Ikuo> Stoyan> > > Ikuo> Stoyan> > > I don't see any discription in the spec about the case that Ikuo> Stoyan> > > a new target service to be bound gets found while a componet Ikuo> Stoyan> > > configuration still keeps satisfied. Ikuo> Stoyan> > > Ikuo> Stoyan> > > Please think about Q2 I had posted. Ikuo> Stoyan> > > Ikuo> Stoyan> > > According to the description in "112.5.2 Satisfied", Ikuo> Stoyan> > > the all three conditions described in 112.5.2 still keep true and Ikuo> Stoyan> > > the component configuration will NOT become unsatisfied. Ikuo> Stoyan> > > Ikuo> Stoyan> > > Therefore it should not be deactivated for answer of Q2. Ikuo> Stoyan> > > Ikuo> Stoyan> > > I mean, the spec should be clarified for this point, shouldn't it? Ikuo> Stoyan> > Ikuo> Stoyan> > You are right. I misspoke in my prior mail for Q2. In Q2 then, since the Ikuo> Stoyan> > component is satisfied, when a new service A is registered, the Ikuo> Stoyan> > component should remain activated. Ikuo> Stoyan> Ikuo> Stoyan> I disagree. Static policy requires deactivation of the component for any Ikuo> Stoyan> change of any of its references. Ikuo> Ikuo> There is no clear description about it in the R4.2 spec. Ikuo> Ikuo> Stoyan> The bind method of a component with a Ikuo> Stoyan> static policy must be called before the component is activated (see Ikuo> Stoyan> 112.4.7 Reference Element). I think we should add a clarification in the Ikuo> Stoyan> chapter where the static policy is described to avoid further confusions. Ikuo> Ikuo> If how the current DS impl of Equinox works is not a bug, Ikuo> I agree with Stoyan. Otherwise, unfortunately I would way the current DS Ikuo> impl of Equinox has a bug. Ikuo> Ikuo> I would like to know how other DS impl, felix, knopflerfish or others, Ikuo> works. Do you know, Richard ? Ikuo> Ikuo> ======= Ikuo> Ikuo YAMASAKI Ikuo> Ikuo> Ikuo> _______________________________________________ Ikuo> OSGi Developer Mail List Ikuo> [email protected] Ikuo> https://mail.osgi.org/mailman/listinfo/osgi-dev Ikuo> _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
