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] > >