Comments inline.
On 9/4/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Ignacio Silva-Lepe wrote:
> > Part of the design of binding-notification is that
> > NotificationReferenceBindingProvider
> > serves as a producer service to handle subscription requests from
> consumers.
> > Because of this, the code was relying on
> > NotificationReferenceBindingProvider
> > being created early, at activation time of components and (component)
> > services.
> > In particular, having NotificationReferenceBindingProvider created at
> the
> > first
> > invocation from its notification component is too late, as no consumer
> will
> > be able
> > to subscribe before any message is sent.
> > There may be a few ways to work around this dynamic creation, which I'll
> try
> > to
> > enumerate, but none of them seem ideal. But my real question is whether
> it
> > would
> > be possible to make this dynamic or "lazy" activation of references
> > optional.
> > That is, would it be possible to let the provider factory interface
> include
> > a
> > supportsDynamicReferenceActivation kind of method. The default return
> value
> > would be true, but if necessary, the method could return false and then
> the
> > composite activator would activate the references for this factory
> eagerly.
> > Thoughts?
> >
> > Dynamic creation work around possiblities:
> > 1- Try to create the producer service in the module activator - One of
> the
> > problems
> > is that producer service activator is implicit and reliant on the values
> of
> > the
> > notificationType and ntm attributes in the binding element, which are
> not
> > known
> > until the binding is processed. Also, the binding object itself does not
> > seem to
> > have a good way to determine the component reference and component that
> it
> > corresponds to and that are needed to activate the producer service.
> > 2- Try to create the producer service when the notification component is
> > started -
> > It is not clear to me that the hooks are there for the implementation
> > provider to
> > do this either, not to mention the fact that this would add a coupling
> of
> > the
> > implementation-notification module to the binding-notification module.
> >
> >
>
> I have two questions:
>
> (1) Is the issue that NotificationReferenceBindingProvider.start() is
> not called until a service invocation reaches the reference? If that's
> the case then it's a bug in the activator algorithm. A
> ReferenceBindingProvider should be started when the component owning the
> reference is started.
In fact, not even NotificationBindingProviderFactory.createReference-
BindingProvider is called until an invocation occurs, as shown by a
trace of a call to it. Moreover, this seems to be working as coded,
unless I misunderstand. Looking at CompositeActivatorImpl.acti-
vate(Composite) you see that only a component's services are acti-
vated, as confirmed by a trace to a call to NotificationBindingProvider-
Factory.createServiceBindingProvider. And, in the trace of createRefe-
renceBindingProvider, you see that it is JDKInvocationHandler.invoke
from the producer component that triggers the creation of the reference
binding provider, via CompositeActivatorImpl.activate(RuntimeCompo-
nent,RuntimeComponentReference).
(2) Your start method looks like this:
> start() {
> if (started) {
> return;
> }
>
> brokerManager.referenceProviderStarted(notificationType, this,
> remoteNtmUrl);
> started = true;
> }
>
> The "if (started) {" test caught my eye, are you seeing the start
> method called several times? If that's the case then it's another bug in
> the activator. If that's not the case then it's a bug in your start
> method, a minor one, since the test is not necessary :)
You call it a bug, I call it defensive programming :-) Either way, as you
point out, it seems to be innocuous.
--
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
