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

On 9 Jul 2014, at 09:33, Heiko Braun <hbraun(a)redhat.com&gt; wrote: > > On 07 Jul 2014, at 16:46, Jeff Mesnil <jmesnil(a)redhat.com&gt; 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.

jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev