Proposal to add notifications to WildFly management model and API
Locked
Proposal to add notifications to WildFly management model and API
 
|
# Add Notification support to WildFly Management
Tracked by https://issues.jboss.org/browse/WFLY-266 Use Cases --------- Notifications are an useful mechanism to observe management changes on WildFly servers. It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.) Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use. The most expected use cases for WildFly notifications are: - enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions. - replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications - integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered) Part 1: Notification Definition ------------------------------- A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource. { "description" => "A manageable resource", "attributes" => { ... }, "operations" => { ... }, "notifications" => { "resource-added" => { ... } }, "children" => { ... } } 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 The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter). The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API. Part 2: Emitting a notification ------------------------------- A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method) public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { // perform some actions ... context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted())); context.stepCompleted(); } The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back. Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation. A Notification is a simple Java class that represents the notification. It is composed of: * type - String - the notification type * address - PathAddress - the address of the resource that emits the notification * message - String - the i18ned description of the message * timestamp - long - the timestamp of the notification. It is set when the Notification object is created. * data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter). If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly. Part 3: Global Resource Notifications —————————————————— In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model: * resource-added - when a resource is added, it emits a resource-added notification * resource-removed - when a resource is removed, it emits a resource-removed notification * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information: * name - String - the name of the attribute * old-value - the detyped representation of the previous value of the attribute * new-value - the detyped representation of the new value Part 4: Notification Handlers —————————————— Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method. The source is a path address to handle notifications emitted by resources at this address. The NotificationHandler is an interface with a single handleNotification(Notification notification) method. The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications. There is a similar unregister method to unregister a (handler, filter) To be useful, the source path address will have to accept wildcards for the address' values: * /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources * /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid). This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI). The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. However until the resource is created, there is no way to register a notification listener on it without using a wildcard. If that proves problematic, we could change this approach with two alternatives: * have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management * the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree…) I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC... Part 5: Domain Notifications —————————————— Notifications are also intended to work in domain mode. In particular, they will be used to observe server state. The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server): * server-started * server-stopped * server-restarted * server-destroyed * server-killed Part 6: Integration with local JMX ————————————————— The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model: * the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo * when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName. * depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered). In a first step, integration will be limited to use of JMX locally. Remoting will not be supported. Part 7: Integration with Remote Management API ——————————————————————— We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter); The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...) The Management HTTP API will also be enhance to support notifications with its REST API. A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets). => the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications Part 8: Integration with Remote JMX ————————————————— Once the WildFly Management API will support notifications (for both native and HTTP), we can add support to JMX remotely (if there is any user interest for it). Part 9: Web Console UX improvement ————————————————— Once the Management HTTP API supports notifications, the Web console can leverage it to improve its UX. This is a task that touch different parts of the app server (mainly in wildfly-core though) and I intend to split it in different JIRA issues (approx. one for each part) that can be merged one after the other instead of a big huge commit. What do you think? jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
Le 07/07/2014 16:46, Jeff Mesnil a écrit :
> Part 7: Integration with Remote Management API > ——————————————————————— > > We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient > > void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter); > > The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...) > > The Management HTTP API will also be enhance to support notifications with its REST API. > A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets). > => the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications Hi Jeff, Just to let you know, in the RHQ team we're also interested in this part, as our Wildfly monitoring is based on the HTTP management interface. I hope we'll be able to find a solution which works nicely with Javascript as well as Java clients. Regards, Thomas _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by Jeff Mesnil
On 7/7/14, 9:46 AM, Jeff Mesnil wrote:
> # Add Notification support to WildFly Management > > Tracked by https://issues.jboss.org/browse/WFLY-266 > > Use Cases > --------- > > Notifications are an useful mechanism to observe management changes on WildFly servers. > It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.) > > Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use. > > The most expected use cases for WildFly notifications are: > - enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions. > - replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications > - integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered) > > Part 1: Notification Definition > ------------------------------- > > A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource. > > { > "description" => "A manageable resource", > "attributes" => { > ... > }, > "operations" => { > ... > }, > "notifications" => { > "resource-added" => { > ... > } > }, > "children" => { > ... > } > } > > 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 > > The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter). > > The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API. > > Part 2: Emitting a notification > ------------------------------- > > A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method) > > public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { > > // perform some actions > ... > > context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted())); > context.stepCompleted(); > } > > The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back. To clarify: I believe your intent was delivery is at the end of the overall operation execution, when it commits, not at the end of the "operation step". I mention this because an operation execution can consist of many steps, with even a basic write involving 2 or 3. > Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation. > > A Notification is a simple Java class that represents the notification. It is composed of: > > * type - String - the notification type > * address - PathAddress - the address of the resource that emits the notification > * message - String - the i18ned description of the message > * timestamp - long - the timestamp of the notification. It is set when the Notification object is created. > * data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter). > > If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly. > We also need to use SecurityManager permissions around the handler registration. Non-remote registrations basically get all permissions, same as internal management clients like the deployment-scanner do. We control the ability of internal management clients like the scanner to create a ModelControllerClient using SecurityManager permissions. > Part 3: Global Resource Notifications > —————————————————— > > In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model: > > * resource-added - when a resource is added, it emits a resource-added notification > * resource-removed - when a resource is removed, it emits a resource-removed notification > * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information: > * name - String - the name of the attribute > * old-value - the detyped representation of the previous value of the attribute > * new-value - the detyped representation of the new value > > > Part 4: Notification Handlers > —————————————— > > Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method. > > The source is a path address to handle notifications emitted by resources at this address. > The NotificationHandler is an interface with a single handleNotification(Notification notification) method. > The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications. > > There is a similar unregister method to unregister a (handler, filter) > > To be useful, the source path address will have to accept wildcards for the address' values: > * /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources > * /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources > > Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid). > > This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI). > > The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. Agreed. I don't think this should be an issue. We shouldn't use the Resource tree anyway as the data structure for retaining the registered handlers; a separate structure is needed. The wildcards are fine as long as there's a relevant ManagementResourceRegistration. > However until the resource is created, there is no way to register a notification listener on it without using a wildcard. > If that proves problematic, we could change this approach with two alternatives: > * have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management > * the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree…) > > I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC... > It's not critical until you get to Part 7 but we'll need to sort it out before even starting on Part 7. The user-related inputs into the existing RBAC logic (see org.jboss.as.controller.access.Authorizer) are the Caller and Environment. The Caller basically just wraps a Subject, exposing the data from the relevant Principal types (name and groups). We could just cache the Caller in effect when the handler is registered and use it for authorizing delivery of each notification. The problem is if the user if no longer valid or the groups associated with the user have changed, this won't be picked up. We don't want to cache any "roles". First, the mapping of the Caller to roles can change from time to time so we don't want to cache that result. Second, "roles" are not first-class parts of the Authorizer API; they are used by our standard impls of it, but we want to allow custom impls that may not care about roles. > Part 5: Domain Notifications > —————————————— > > Notifications are also intended to work in domain mode. In particular, they will be used to observe server state. > > The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server): > * server-started > * server-stopped > * server-restarted > * server-destroyed > * server-killed > > Part 6: Integration with local JMX > ————————————————— > > The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model: > * the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo > * when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName. > * depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered). > > In a first step, integration will be limited to use of JMX locally. Remoting will not be supported. > Everything up to this point I'd like to see in 8.2. > Part 7: Integration with Remote Management API > ——————————————————————— > > We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient > > void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter); > > The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...) > Last we talked about this we planned to do a new controller client variant that could better handle this. > The Management HTTP API will also be enhance to support notifications with its REST API. > A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets). > => the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications > > Part 8: Integration with Remote JMX > ————————————————— > > Once the WildFly Management API will support notifications (for both native and HTTP), we can add support to JMX remotely (if there is any user interest for it). > > Part 9: Web Console UX improvement > ————————————————— > > Once the Management HTTP API supports notifications, the Web console can leverage it to improve its UX. > > This is a task that touch different parts of the app server (mainly in wildfly-core though) and I intend to split it in different JIRA issues (approx. one for each part) that can be merged one after the other instead of a big huge commit. > > What do you think? > Sounds good. > jeff > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by Jeff Mesnil
On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote: The description of a notification will be composed of: I assume there will be default notification types provided by all resources and specific notifications types that subsystems can introduce? How do we get to the supported types that resources can emit? Will there be a textual description, similar to read-resource-description() Regards, Heiko _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
On 9 Jul 2014, at 09:33, Heiko Braun <[hidden email]> wrote: > > On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> 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 [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by Brian Stansberry
On 8 Jul 2014, at 23:07, Brian Stansberry <[hidden email]> wrote: > On 7/7/14, 9:46 AM, Jeff Mesnil wrote: >> # Add Notification support to WildFly Management >> >> Tracked by https://issues.jboss.org/browse/WFLY-266 >> >> Use Cases >> --------- >> >> Notifications are an useful mechanism to observe management changes on WildFly servers. >> It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.) >> >> Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use. >> >> The most expected use cases for WildFly notifications are: >> - enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions. >> - replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications >> - integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered) >> >> Part 1: Notification Definition >> ------------------------------- >> >> A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource. >> >> { >> "description" => "A manageable resource", >> "attributes" => { >> ... >> }, >> "operations" => { >> ... >> }, >> "notifications" => { >> "resource-added" => { >> ... >> } >> }, >> "children" => { >> ... >> } >> } >> >> 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 >> >> The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter). >> >> The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API. >> >> Part 2: Emitting a notification >> ------------------------------- >> >> A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method) >> >> public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { >> >> // perform some actions >> ... >> >> context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted())); >> context.stepCompleted(); >> } >> >> The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back. > > To clarify: I believe your intent was delivery is at the end of the > overall operation execution, when it commits, not at the end of the > "operation step". I mention this because an operation execution can > consist of many steps, with even a basic write involving 2 or 3. You are right, my description was not correct. The notifications are all emitted at the end of the overall operation execution after it commits. Either all notifications are emitted or none are. > >> Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation. >> >> A Notification is a simple Java class that represents the notification. It is composed of: >> >> * type - String - the notification type >> * address - PathAddress - the address of the resource that emits the notification >> * message - String - the i18ned description of the message >> * timestamp - long - the timestamp of the notification. It is set when the Notification object is created. >> * data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter). >> >> If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly. >> > > We also need to use SecurityManager permissions around the handler > registration. Non-remote registrations basically get all permissions, > same as internal management clients like the deployment-scanner do. We > control the ability of internal management clients like the scanner to > create a ModelControllerClient using SecurityManager permissions. > >> Part 3: Global Resource Notifications >> —————————————————— >> >> In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model: >> >> * resource-added - when a resource is added, it emits a resource-added notification >> * resource-removed - when a resource is removed, it emits a resource-removed notification >> * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information: >> * name - String - the name of the attribute >> * old-value - the detyped representation of the previous value of the attribute >> * new-value - the detyped representation of the new value >> > >> >> Part 4: Notification Handlers >> —————————————— >> >> Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method. >> >> The source is a path address to handle notifications emitted by resources at this address. >> The NotificationHandler is an interface with a single handleNotification(Notification notification) method. >> The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications. >> >> There is a similar unregister method to unregister a (handler, filter) >> >> To be useful, the source path address will have to accept wildcards for the address' values: >> * /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources >> * /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources >> >> Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid). >> >> This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI). >> >> The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. > > Agreed. I don't think this should be an issue. We shouldn't use the > Resource tree anyway as the data structure for retaining the registered > handlers; a separate structure is needed. The wildcards are fine as long > as there's a relevant ManagementResourceRegistration. In my POC, I am using a single Map to retain the handler and is separate from the resource tree. The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses). When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification. I.e. the data structure grows with the number of handlers, not with the resources that emits notifications. >> However until the resource is created, there is no way to register a notification listener on it without using a wildcard. >> If that proves problematic, we could change this approach with two alternatives: >> * have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management >> * the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree…) >> >> I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC... >> > > It's not critical until you get to Part 7 but we'll need to sort it out > before even starting on Part 7. > > The user-related inputs into the existing RBAC logic (see > org.jboss.as.controller.access.Authorizer) are the Caller and > Environment. The Caller basically just wraps a Subject, exposing the > data from the relevant Principal types (name and groups). > > We could just cache the Caller in effect when the handler is registered > and use it for authorizing delivery of each notification. The problem is > if the user if no longer valid or the groups associated with the user > have changed, this won't be picked up. > > We don't want to cache any "roles". First, the mapping of the Caller to > roles can change from time to time so we don't want to cache that > result. Second, "roles" are not first-class parts of the Authorizer API; > they are used by our standard impls of it, but we want to allow custom > impls that may not care about roles. > >> Part 5: Domain Notifications >> —————————————— >> >> Notifications are also intended to work in domain mode. In particular, they will be used to observe server state. >> >> The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server): >> * server-started >> * server-stopped >> * server-restarted >> * server-destroyed >> * server-killed >> >> Part 6: Integration with local JMX >> ————————————————— >> >> The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model: >> * the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo >> * when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName. >> * depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered). >> >> In a first step, integration will be limited to use of JMX locally. Remoting will not be supported. >> > > Everything up to this point I'd like to see in 8.2. I have create JIRA issues for the parts (as dependencies of the umbrella issue http://issues.jboss.org//browse/WFLY-266) and set their fix versions for both 8.2.0.CR1 and 9.0.0.Alpha1. -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
|
|
In reply to this post by Jeff Mesnil
On 10 Jul 2014, at 10:41, Jeff Mesnil <[hidden email]> wrote: > > On 9 Jul 2014, at 09:33, Heiko Braun <[hidden email]> wrote: > >> >> On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> 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 > [hidden email] > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by Jeff Mesnil
On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote: > # Add Notification support to WildFly Management > > Tracked by https://issues.jboss.org/browse/WFLY-266 > > Part 1: Notification Definition > Part 2: Emitting a notification > Part 4: Notification Handlers => The 3 parts were done in WFLY-266[1] > Part 3: Global Resource Notifications => done in WFLY-3603[2] > Part 5: Domain Notifications => code to emit notifications in domain mode is trivial[3] but I can’t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC). So far, we have in master branch all we wanted to put in 8.2 and I’ll backport it. > Part 6: Integration with local JMX For this part, we only want to enable local JMX notifications. This would allow to use JMX notifications from WildFly through access of its MBeanServerService only. * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server) * Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine) * Using remote connection via our remoting-jmx connector does *not* work We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX. As it stands now, the integration in JMX is quite limited as only subsystems can access them. Another thing I’m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward. * when a resource is added/removed, the notification is emitted at at is location in the resource trees => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead * when an attribute changes, the type of the JMX notification remains attribute-value-written => Does it make sense to convert that to JMX AttributeChangeNotification? * A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that. I’m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration. Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not “leak” notifications to the outside with critical information until we have proper RBAC support for it. Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time. wdyt? jeff [1] http://issues.jboss.org//browse/WFLY-266 [2] https://issues.jboss.org/browse/WFCORE-28 [3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
|
Administrator
|
In reply to this post by Jeff Mesnil
On Jul 10, 2014, at 4:52 AM, Jeff Mesnil <[hidden email]> wrote: > > On 8 Jul 2014, at 23:07, Brian Stansberry <[hidden email]> wrote: > >> On 7/7/14, 9:46 AM, Jeff Mesnil wrote: -snip- >>> The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. >> >> Agreed. I don't think this should be an issue. We shouldn't use the >> Resource tree anyway as the data structure for retaining the registered >> handlers; a separate structure is needed. The wildcards are fine as long >> as there's a relevant ManagementResourceRegistration. > > In my POC, I am using a single Map to retain the handler and is separate from the resource tree. > The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses). > When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification. > I.e. the data structure grows with the number of handlers, not with the resources that emits notifications. Is this map broken up into path segments to mitigate the o(n) cost? e.g.determining if /x=blah/y=foo/z=bar matches x=blah/y=foo/* = 2 O(1) map lookups -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
|
|
In reply to this post by Jeff Mesnil
On 4 Aug 2014, at 14:51, Jeff Mesnil <[hidden email]> wrote: > > On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote: > >> # Add Notification support to WildFly Management >> >> Tracked by https://issues.jboss.org/browse/WFLY-266 >> >> Part 1: Notification Definition >> Part 2: Emitting a notification >> Part 4: Notification Handlers > > => The 3 parts were done in WFLY-266[1] > >> Part 3: Global Resource Notifications > > => done in WFLY-3603[2] > >> Part 5: Domain Notifications > > => code to emit notifications in domain mode is trivial[3] but I can’t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC). > > So far, we have in master branch all we wanted to put in 8.2 and I’ll backport it. > >> Part 6: Integration with local JMX > > For this part, we only want to enable local JMX notifications. > This would allow to use JMX notifications from WildFly through access of its MBeanServerService only. > > * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server) > * Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine) > * Using remote connection via our remoting-jmx connector does *not* work > > We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX. > > As it stands now, the integration in JMX is quite limited as only subsystems can access them. > > Another thing I’m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward. > * when a resource is added/removed, the notification is emitted at at is location in the resource trees > => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate > => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead > * when an attribute changes, the type of the JMX notification remains attribute-value-written > => Does it make sense to convert that to JMX AttributeChangeNotification? > * A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that. > > I’m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration. > Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not “leak” notifications to the outside with critical information until we have proper RBAC support for it. > > Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time. > > wdyt? > jeff > > [1] http://issues.jboss.org//browse/WFLY-266 > [2] https://issues.jboss.org/browse/WFCORE-28 > [3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
On 04 Aug 2014, at 16:40, Kabir Khan <[hidden email]> wrote: >>> Part 6: Integration with local JMX >> >> For this part, we only want to enable local JMX notifications. >> This would allow to use JMX notifications from WildFly through access of its MBeanServerService only. >> >> * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server) > If that is true, that is a bug - we put some hooks into JBoss Modules ages ago to make the pluggable mbean server the platform mbean server. Are you seeing this in wildfly-core or wildfly? You’re correct: the ManagementFactory.getPlatformMBeanServer() is our pluggable mbean server (I’ve been tricked by the tests that does not make the MBeanServerBuilder thingie). So our notifications can be used by JMX client through the ManagementFactory.getPlatformMBeanServer() too. -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by Jeff Mesnil
On 8/4/14, 8:51 AM, Jeff Mesnil wrote:
> > On 07 Jul 2014, at 16:46, Jeff Mesnil <[hidden email]> wrote: > >> # Add Notification support to WildFly Management >> >> Tracked by https://issues.jboss.org/browse/WFLY-266 >> >> Part 1: Notification Definition >> Part 2: Emitting a notification >> Part 4: Notification Handlers > > => The 3 parts were done in WFLY-266[1] > >> Part 3: Global Resource Notifications > > => done in WFLY-3603[2] > >> Part 5: Domain Notifications > > => code to emit notifications in domain mode is trivial[3] but I can’t test it out since there is no current way to connect to the DC and listen for notifications. I will defer this after we add notification support for our remote controller API (or if someone has a compelling use case to use these notifications from inside the DC). > > So far, we have in master branch all we wanted to put in 8.2 and I’ll backport it. > >> Part 6: Integration with local JMX > > For this part, we only want to enable local JMX notifications. > This would allow to use JMX notifications from WildFly through access of its MBeanServerService only. > > * Using in-vm ManagementFactory.getPlatformMBeanServer() does *not* work (WildFly facade MBeans are not registered in this MBean server) > * Using remote connection via the Attach API does *not* work (e.g. when you connect using jconsole/jvisualvm from the same machine) > * Using remote connection via our remoting-jmx connector does *not* work > > We first need to support RBAC and support notifications from our own remote management API (native + HTTP) before allowing it for JMX. > > As it stands now, the integration in JMX is quite limited as only subsystems can access them. > > Another thing I’m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward. > * when a resource is added/removed, the notification is emitted at at is location in the resource trees > => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate > => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead Are you saying the standard MBeanServerNotification via JMImplementation:type=MBeanServerDelegate wouldn't work? I think it should. > * when an attribute changes, the type of the JMX notification remains attribute-value-written > => Does it make sense to convert that to JMX AttributeChangeNotification? That seems like the intuitive thing to do, and anyone trying to use JMX to monitor the system would expect such notifications. Why wouldn't we do that? > * A more specific question would be about jconsole/jvisualvm support? As an example: if a resource is added to WildFly, jconsole UI tree will not be refreshed to display the new MBean since it listens to notifications on the JMImplementation:type=MBeanServerDelegate for that. > > I’m about to submit the PR to add local JMX notification to WildFly but I wanted to make sure we agree on the scope of the JMX integration. > Preventing notifications from remote connections makes from some ugly code (as JMX is designed to not care if the MBean server connection is local or remote) but it is important we do not “leak” notifications to the outside with critical information until we have proper RBAC support for it. > > Maybe, I should add RBAC support now and propose a single PR for the local JMX integration and RBAC at the same time. > How complex would the RBAC support be? I'm reluctant to try for something in any way complex at this stage. > wdyt? > jeff > > [1] http://issues.jboss.org//browse/WFLY-266 > [2] https://issues.jboss.org/browse/WFCORE-28 > [3] https://github.com/jmesnil/wildfly-core/tree/WFLY-3602_domain_server_notifications > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by jtgreene
On 04 Aug 2014, at 16:27, Jason Greene <[hidden email]> wrote: POC, I am using a single Map to retain the handler and is separate from the resource tree. >> The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses). >> When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification. >> I.e. the data structure grows with the number of handlers, not with the resources that emits notifications. > > Is this map broken up into path segments to mitigate the o(n) cost? > > e.g.determining if /x=blah/y=foo/z=bar matches x=blah/y=foo/* = 2 O(1) map lookups This is definitely something I need to do to decrease the lookup cost. I’ll have a look if I can reuse the code from our resource registry for that. thanks, jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by Brian Stansberry
On 04 Aug 2014, at 21:36, Brian Stansberry <[hidden email]> wrote: >> Another thing I’m still considering is how much idiomatic the JMX integration should be. At the moment, the conversion from WildFly notifications to JMX is straightforward. >> * when a resource is added/removed, the notification is emitted at at is location in the resource trees >> => in JMX, registering/unregistering a MBean emits notifications at a single location in the JMImplementation:type=MBeanServerDelegate >> => Users wanted to capture our facade means notifications would have to register their listener against the jboss.as:* ObjectName pattern instead > > Are you saying the standard MBeanServerNotification via > JMImplementation:type=MBeanServerDelegate wouldn't work? I think it should. > >> * when an attribute changes, the type of the JMX notification remains attribute-value-written >> => Does it make sense to convert that to JMX AttributeChangeNotification? > > That seems like the intuitive thing to do, and anyone trying to use JMX > to monitor the system would expect such notifications. Why wouldn't we > do that? As a followup, I’ve submitted a PR for the local JMX notifications with your suggestion: * resource-added/removed are converted to MBeanServerNotification emitted by JMImplementation:type=MBeanServerDelegate * attribute-value-written are converted to AttributeChangeNotifcation emitted by the resource itself. jeff [1] https://github.com/wildfly/wildfly-core/pull/82 -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by Brian Stansberry
Am 04.08.2014 um 21:36 schrieb Brian Stansberry <[hidden email]>: >> * when an attribute changes, the type of the JMX notification remains attribute-value-written >> => Does it make sense to convert that to JMX AttributeChangeNotification? > > That seems like the intuitive thing to do, and anyone trying to use JMX > to monitor the system would expect such notifications. Why wouldn't we > do that? +1 There is so much tooling for JMX available that this should be treated as a first class citizen. _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
|
|
In reply to this post by Jeff Mesnil
Hi guys
Can you please tell me if the support for notifications is embedded in wildfly 81.0-Final ?* I'm migrating an ear from 4.3EAP to wildfly and my application relies on startup stop jmx notifications to start some treatments. As a result, my application does not run correctly because of the absence of this feature. Could you please suggest me an alternative supplied by widfly to solve my problem ? thank you |
Re: Proposal to add notifications to WildFly management model and API
|
|
Support for WildFly notifications has been backported to 8.2.0.CR1.
It is not in 8.1.0.Final. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
|
|
Thank you for the quick response.
I know it is not the right place to talk about it but where can i find this version ? It did not appears on download section of the website ? Best regards |
Re: Proposal to add notifications to WildFly management model and API
|
|
In reply to this post by Jeff Mesnil
On github. Branch 8.x.
It is not released yet. But you can try with 9.0.0.Alpha1 which also has notifications. Sent from my PhoneFrom: weedfly Sent: 20.10.2014 16:23 To: [hidden email] Subject: Re: [wildfly-dev] Proposal to add notifications to WildFly management model and API Thank you for the quick response. I know it is not the right place to talk about it but where can i find this version ? It did not appears on download section of the website ? Best regards -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/Proposal-to-add-notifications-to-WildFly-management-model-and-API-tp5714484p5715143.html Sent from the WildFly Development mailing list archive at Nabble.com. _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev |
|
|
Oki,
I tried with 9.0.0.Alpha1 but i receive only one notification (jmx attribute change) and not the start / stop notifications. I register my listener this way: final ObjectName webServerName = ObjectName.getInstance("jboss.web:service=WebServer"); LOGGER.debug("Enregistrement du listener pour le mbean jboss.web:service=WebServer"); mBeanserver.addNotificationListener(webServerName, this, null, null); LOGGER.debug("Récupération du mbean jboss.system:type=Server"); final ObjectName serverName = ObjectName.getInstance("jboss.system:type=Server"); LOGGER.debug("Enregistrement du listener pour le mbean jboss.system:type=Server"); mBeanserver.addNotificationListener(serverName, this, null, null); LOGGER.info("Fin de l'initialisation du listener"); Is it still the way to do it or do wildfly supply a new API to register listeners ? Thank you for your help. |
«
Return to WildFly Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |