Hi BJ and all, On Wed, 22 Jul 2009 09:37:21 -0400 BJ Hargrave <[email protected]> wrote:
BJ> > Could you tell me which descriptions in the spec address the use of BJ> > static policy with BJ> > multiple cardinality in order to answer Q1 and Q2 ? BJ> BJ> See 112.5.7: "When a component configuration's reference is satisfied, BJ> there is a set of BJ> zero or more target services for that reference. When the component BJ> config- BJ> uration is activated, a subset of the target services for each reference BJ> are BJ> bound to the component configuration. The subset is chosen by the cardi- BJ> nality of the reference. See Reference Cardinality on page306." Although I understand the underlieing idea, I don't think I am convinced completely regarding the description of the spec. I don't see any discription in the spec about the case that a new target service to be bound gets found while a componet configuration still keeps satisfied. Please think about Q2 I had posted. According to the description in "112.5.2 Satisfied", the all three conditions described in 112.5.2 still keep true and the component configuration will NOT become unsatisfied. Therefore it should not be deactivated for answer of Q2. I mean, the spec should be clarified for this point, shouldn't it? > --------------------------- > > Precondition2: component1 has a STATIC reference with cardinaliry of > "1..n" for serviceA. There is one serviceA registered. > ==> component1 has been already activated. > > Q2. What will happen if serviceA is registered at Precondition2 ? BJ> > As far as I see, the second paragraphin of section 112.3.3 "Reference BJ> > Policy" says: BJ> > BJ> > "Component configurations are deactivated before any bound BJ> > service for a reference having a static policy BJ> > becomes unavailable. If a target service is available to replace the BJ> bound BJ> > service which became unavailable, the component configuration must be BJ> > reactivated and bound to the replacement service." BJ> > BJ> > But it doesn't says in the case that the service already bound keeps BJ> > available and new service to be bound becomes available. BJ> BJ> Then the component is still satisfied and does not need to be deactivated. That's right. BJ> > On the other hand, I found another sentence which might imply the BJ> answers. BJ> > BJ> > The 5th paragraph of section 112.3.3 "Reference Policy" says: BJ> > BJ> > "The previous example with the registering of a resource BJ> > directory used a static policy. This implied that the component BJ> > configurations are deactivated when there is a change in the bound set BJ> > of Http Services." BJ> > BJ> > (The example has the STATIC reference with multiple cardinality) BJ> BJ> If the set of target services changes such that a bound service is no BJ> longer in the target set, BJ> then that service must be unbound. If the reference is static, then the BJ> component must be deactivated. BJ> BJ> A change in the set of target services does not necessarily result in a BJ> change in the set of bound services. I got it. BJ> > BJ> There is no need to replace the service since the currently bound BJ> service BJ> > BJ> is still available. But since the policy is dynamic, a DS impl could BJ> BJ> > BJ> replace the service if it wanted to. BJ> > BJ> > Does it mean that some DS impls might replace and the others might not BJ> > replace (It is up to a DS impl) ? BJ> BJ> I think this is the case but I would expect DS impl to lean to the side of BJ> stability. That is, only reactivate a component if necessary not just BJ> because it can. I understand your opinion. ======= Ikuo YAMASAKI _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
