Re: Issue with dynamic creation of NotificationReferenceBindingProvider

[Ignacio Silva-Lepe <is...@gmail.com>]

So, more specifically, I'd like to propose the following
changes:

1- Add a boolean supportsDynamicReferenceActivation
method to o.a.t.s.provider.BindingProviderFactory
2- Change o.a.t.s.core.Assembly.CompositeActivator-
Impl.activate(Composite) to once again call activate
for a component's RuntimeComponentReferences and
indicating to it that this is a static activation
3- Change o.a.t.s.core.Assembly.CompositeActivator-
Impl.activate(RuntimeComponent,RuntimeComponent-
Reference) to delegate to a private version that takes
a boolean isDynamicActivation
4- Add an activate(RuntimeComponent,RuntimeCom-
ponentReference,boolean) method to o.a.t.s.core.Assem-
bly.CompositeActivatorImpl that does the bulk of the
work and that only does it if the binding provider factory
at hand agrees with the dynamic activation boolean
parameter value.

Notice that step 1 above is a change to the core spi but,
in my opinion, it is only making explicit the change that
has already been made implicitly. That is, the change to
a dynamic activation of reference binding providers is,
in my opinion, an implicit change to the spi.
Thoughts?


On 8/30/07, Ignacio Silva-Lepe <is...@gmail.com> 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.
>