[wildfly-dev] Proposal to add notifications to WildFly management model and API

[Kabir Khan]

On 10 Jul 2014, at 10:41, Jeff Mesnil <jmesnil at redhat.com> wrote:

> 
> On 9 Jul 2014, at 09:33, Heiko Braun <hbraun at redhat.com> wrote:
> 
>> 
>> On 07 Jul 2014, at 16:46, Jeff Mesnil <jmesnil at redhat.com> wrote:
>> 
>>> The description of a notification will be composed of:
>>> 
>>> * type - String - the type of notification (resource-added, server-stopped, etc.)
>>> * description - String - i18ned description of the notification
>>> * access-constraints - the RBAC access constraints that controls who can receive the notifications
>>> * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value
>> 
>> 
>> I assume there will be default notification types provided by all resources and specific notifications types that subsystems can introduce?
> 
> Yes, default notification types provided by all resources are described in Part 3: Global Resource Notifications and would be resource-added, resource-removed and attribute-value-written.
> 
> Specific notification types can then be introduced by any resource. For example, in domain mode, the /host=X/server-config=Y resource will emit notifications for server lifecycle (started, stopped, killed, etc.) as described in Part 5: Domain Notifications.
> 
> Once the notification support is put into WildFy core, subsystems would be able to leverage them. For example, I plan to add a notification in the messaging subsystem when failover occurs and a backup server becomes live.
> 
>> How do we get to the supported types that resources can emit? Will there be a textual description, similar to read-resource-description()
> 
> The notification types will be put into the read-resource-description operation as described in Part 1: Notification Definition.
> A management client would be able to know which notifications can be emitted by the resource by calling :read-resource-description(notifications=true).
> The notification definition has a i18ned description attribute that is human-readable.
> 
> In my current prototype, I have a design issue because a resource can emit a notification without having a corresponding notification definition in its description. I’m not sure if that is a significant issue. If a resource emits a notification without describing it, it would not help clients discover that it is emitted. On the other hand, if I want to enforce that, I can only do it when the notification is emitted at runtime and I am not sure it is a good idea (the server would boot fine and only when the code is run, it would become apparent the resource is incorrectly defined…). I am still pondering what is the best way to handle this but ideally I want the resource description to be consistent with the notifications that are effectively emitted by the resource.
Not enforcing, a big fat warning if not defined, and some asserts to pick this up during testing when assertions are enabled could be a happy middle ground. We can probably add some notification testing to model-/subsystem-/core-model-test as well.
> 
> jeff
> 
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev