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.
