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
----- Original Message -----
From: "Ignacio Silva-Lepe" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 05, 2007 5:52 AM
Subject: Re: Issue with dynamic creation of
NotificationReferenceBindingProvider
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
