Ever since the early days of Service Binder, the static policy has meant
that the component ignores service additions after activation (i.e., it
doesn't deactivate/reactivate), the only changes that impact a component
with static policies are removal of services being used by the component
(at which time it will certainly deactivate and then may reactivate with
new services if replacements are available).
I am not positive that Felix' DS impl behaves this way, but I hope it does.
-> richard
On 7/27/09 10:44 AM, Ikuo Yamasaki wrote:
Hi Stoyan
On Mon, 27 Jul 2009 11:10:37 +0300
Stoyan Boshev<[email protected]> wrote:
Stoyan>
Stoyan> BJ Hargrave wrote:
Stoyan> > > BJ> > Could you tell me which descriptions in the spec
address the
Stoyan> > use of
Stoyan> > > BJ> > static policy with
Stoyan> > > BJ> > multiple cardinality in order to answer Q1 and Q2 ?
Stoyan> > > BJ>
Stoyan> > > BJ> See 112.5.7: "When a component configuration's reference is
Stoyan> > satisfied,
Stoyan> > > BJ> there is a set of
Stoyan> > > BJ> zero or more target services for that reference. When the
component
Stoyan> > > BJ> config-
Stoyan> > > BJ> uration is activated, a subset of the target services for
each
Stoyan> > reference
Stoyan> > > BJ> are
Stoyan> > > BJ> bound to the component configuration. The subset is chosen
by the
Stoyan> > cardi-
Stoyan> > > BJ> nality of the reference. See Reference Cardinality on
page306."
Stoyan> > >
Stoyan> > > Although I understand the underlieing idea,
Stoyan> > > I don't think I am convinced completely regarding the
description
Stoyan> > ofthe spec.
Stoyan> > >
Stoyan> > > I don't see any discription in the spec about the case that
Stoyan> > > a new target service to be bound gets found while a componet
Stoyan> > > configuration still keeps satisfied.
Stoyan> > >
Stoyan> > > Please think about Q2 I had posted.
Stoyan> > >
Stoyan> > > According to the description in "112.5.2 Satisfied",
Stoyan> > > the all three conditions described in 112.5.2 still keep true
and
Stoyan> > > the component configuration will NOT become unsatisfied.
Stoyan> > >
Stoyan> > > Therefore it should not be deactivated for answer of Q2.
Stoyan> > >
Stoyan> > > I mean, the spec should be clarified for this point, shouldn't
it?
Stoyan> >
Stoyan> > You are right. I misspoke in my prior mail for Q2. In Q2 then,
since the
Stoyan> > component is satisfied, when a new service A is registered, the
Stoyan> > component should remain activated.
Stoyan>
Stoyan> I disagree. Static policy requires deactivation of the component for
any
Stoyan> change of any of its references.
There is no clear description about it in the R4.2 spec.
Stoyan> The bind method of a component with a
Stoyan> static policy must be called before the component is activated (see
Stoyan> 112.4.7 Reference Element). I think we should add a clarification in
the
Stoyan> chapter where the static policy is described to avoid further
confusions.
If how the current DS impl of Equinox works is not a bug,
I agree with Stoyan. Otherwise, unfortunately I would way the current DS
impl of Equinox has a bug.
I would like to know how other DS impl, felix, knopflerfish or others,
works. Do you know, Richard ?
=======
Ikuo YAMASAKI
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
