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.

Reply via email to