Comments inline. On 9/5/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Comments inline. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> > To: <tuscany-dev@ws.apache.org> > Sent: Wednesday, September 05, 2007 9:03 AM > Subject: Re: Issue with dynamic creation of > NotificationReferenceBindingProvider > > > > [snip] > > Raymond Feng wrote: > >> At this moment, the code works as Ignacio described. We defer the > >> activation of a reference to the first time it's used for invocation. > If > >> we decide that we need to agressively start the reference bindings, we > >> can add the part back to CompositeActivatorImpl. > >> > >> Thanks, > >> Raymond > >> > > > > I think we need to activate references when the component that owns them > > is activated, to keep the semantics of of start()/stop() clear, and > allow > > providers to perform any initialization they need on references (which > are > > not so different from services in many aspects). > > There are some differences. A reference can be dynamically created and it > is > possible that a reference binding won't be selected at all. > > As a balance, can we do the following? > > 1) During the activation of a component, we add the reference binding > providers to the defined references. Then the binding provider will have a > chance to do some initialization (for example, handle subscription). > > 2) When the reference is used for invocation, we start the binding > provider > (further initilization can be performed at this time) and create the > wire/invocation chains.
This may not work for the broker case. To determine whether a producer is part of a broker, the provider factory relies on being able to tell whether a consumer (or service) provider is present. For this, the provider factory assumes that at start time of the providers, they have been created if they are ever going to be. So the start call to the reference binding provider needs to happen early as well. Letting dynamic creation be optional with a default of true seems to me to be a good compromise for this reason. Thanks, > Raymond > > > > > -- > > Jean-Sebastien > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
