> Hi BJ, > > Thank you for answering my questions. > > On Tue, 21 Jul 2009 10:05:18 -0400 > BJ Hargrave <[email protected]> wrote: > > BJ> > Hi all, > BJ> > > BJ> > I have several questions on DS Spec. > BJ> > > BJ> > ============================================== > BJ> > [Background] > BJ> > > BJ> > In 112.3.3 Reference Policy of R4.2 cmpn spec, "Static policy is usually > BJ> > also not applicable if the cardinality specifies multiple bound > BJ> > services.". > BJ> > > BJ> > However, spec doesn't specifies what will happen if static policy with > BJ> > the cardinality which specifies multiple bound. > BJ> > BJ> That sentence is just commentary. If a component depends upon multiple > BJ> services, then is probably wants that to be a dynamic dependency. > BJ> > BJ> I think the spec quite well addresses the use of static policy with > BJ> multiple cardinality. > BJ> > BJ> > > BJ> > This caused several questions on DS: > BJ> > > BJ> > ============================================== > BJ> > > BJ> > Precondition1: component1 has a static reference with cardinaliry of > BJ> > "0..n" for serviceA. There is no serviceA registered. > BJ> > ==> component1 has been already activated. > BJ> > > BJ> > Q1. What will happen if serviceA is registered at Precondition1 ? > BJ> > BJ> > BJ> If component1 is activated with 0 bound serviceA and a serviceA is then > BJ> registered, component1 should be deactivated. Then a new component1 is > BJ> created, bound to 1 serviceA and activated. > > BJ> > --------------------------- > BJ> > > BJ> > Precondition2: component1 has a STATIC reference with cardinaliry of > BJ> > "1..n" for serviceA. There is one serviceA registered. > BJ> > ==> component1 has been already activated. > BJ> > > BJ> > Q2. What will happen if serviceA is registered at Precondition2 ? > BJ> > BJ> If component1 is activated with 1 bound serviceA and a serviceA is then > BJ> registered, component1 should be deactivated. Then a new component1 is > BJ> created, bound to 2 serviceA and activated. > > Could you tell me which descriptions in the spec address the use of > static policy with > multiple cardinality in order to answer Q1 and Q2 ?
See 112.5.7: "When a component configuration’s reference is satisfied, there is a set of zero or more target services for that reference. When the component config- uration is activated, a subset of the target services for each reference are bound to the component configuration. The subset is chosen by the cardi- nality of the reference. See Reference Cardinality on page306." > > As far as I see, the second paragraphin of section 112.3.3 "Reference > Policy" says: > > "Component configurations are deactivated before any bound > service for a reference having a static policy > becomes unavailable. If a target service is available to replace the bound > service which became unavailable, the component configuration must be > reactivated and bound to the replacement service." > > But it doesn't says in the case that the service already bound keeps > available and new service to be bound becomes available. Then the component is still satisfied and does not need to be deactivated. > > On the other hand, I found another sentence which might imply the answers. > > The 5th paragraph of section 112.3.3 "Reference Policy" says: > > "The previous example with the registering of a resource > directory used a static policy. This implied that the component > configurations are deactivated when there is a change in the bound set > of Http Services." > > (The example has the STATIC reference with multiple cardinality) If the set of target services changes such that a bound service is no longer in the target set, then that service must be unbound. If the reference is static, then the component must be deactivated. A change in the set of target services does not necessarily result in a change in the set of bound services. > > BJ> > --------------------------- > BJ> > > BJ> > Precondition3: component1 has a STATIC reference with cardinaliry of > BJ> > "1..1" for serviceA. There is one serviceA registered. > BJ> > ==> component1 has been already activated. > BJ> > > BJ> > Q3. What will happen if another serviceA with higher SERVICE_RANKING > BJ> than > BJ> > the bound service is registered at Precondition3 ? > BJ> > > BJ> > Should it be bound service replaced (and re-activate after > BJ> > deactivattion) ? or not. > BJ> > BJ> There is no need to replace the service since 1..1 static dependencies do > BJ> not require replacement as long as the current bound service is still > BJ> available. > > I got it. That is what I had understand from the spec. > > BJ> > --------------------------- > BJ> > > BJ> > Precondition4: component1 has a DYNAMIC reference with cardinaliry of > BJ> > "1..1" for serviceA. There is one serviceA registered. > BJ> > ==> component1 has been already activated. > BJ> > > BJ> > Q4. What will happen if another serviceA with higher SERVICE_RANKING > BJ> than > BJ> > the bound service is registered at Precondition4 ? > BJ> > > BJ> > Should it be bound service replaced (and re-bind the new and unbind the > BJ> > old) ? or not. > BJ> > BJ> There is no need to replace the service since the currently bound service > BJ> is still available. But since the policy is dynamic, a DS impl could > BJ> replace the service if it wanted to. > > Does it mean that some DS impls might replace and the others might not > replace (It is up to a DS impl) ? I think this is the case but I would expect DS impl to lean to the side of stability. That is, only reactivate a component if necessary not just because it can. > > It seems to me that a DS impl must NOT replace it, taking the > consistency of Q3 (STATIC policy case) it into account. > > What do you think ? > -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
