11:41 a.m.
On 9 Jul 2014, at 09:33, Heiko Braun <hbraun(a)redhat.com> wrote:
On 07 Jul 2014, at 16:46, Jeff Mesnil <jmesnil(a)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.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/