New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WFLY-266] Notification Support #23
Conversation
*/ | ||
class NotificationSupportImpl implements NotificationSupport { | ||
|
||
private final Map<PathAddress, Set<NotificationHandlerEntry>> notificationHandlers = new HashMap<PathAddress, Set<NotificationHandlerEntry>>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of this map needs to be made thread safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see comment just below
Re: 8.x, the change to ModelController is fine -- that's not an interface outsiders are meant to be implementing. ResourceDefinition is more of an issue as that's a class people might be implementing themselves. For RBAC I added https://github.com/bstansberry/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/access/management/ConstrainedResourceDefinition.java so doing something like that in your new "notifications" package is a possibility. I see I never deprecated ConstrainedResourceDefinition. I'd better do that now in 8.x and remove it in 9! |
@bstansberry I've amended the commit with your remarks. |
* add notifications to AS7 resources description notifications are described in :read-resource-description operation if the notifications boolean is true * NotificationDefinition let any resources describe the notifications they can emit by registering them in the ManagementResourceRegistration * add NotificationRegistry (exposed by the ModelController) to register/unregister notification handlers * add NotificationSupport to emit notifications during a managemenet operations (through OperationContext.emit(Notification)) Notifications emitted by OperationContext.emit(Notification) are effectively sent at the end of the operation execution if it is successful. This ensure that the order of notifications emitted by a single OperationContext will be received in the same order (unless they are emitted during the ResultHandler execuion). If the NotificationSupport is created with an ExecutorService, the delivery of notifications is non-blocking and will not block the remaining code path of the operation execution. JIRA: https://issues.jboss.org/browse/WFLY-266
Superceded by #42, which was just a minor rebase of this. I merged that one. |
* add notifications to AS7 resources description notifications are described in :read-resource-description operation if the notifications boolean is true * NotificationDefinition let any resources describe the notifications they can emit by registering them in the ManagementResourceRegistration * add NotificationRegistry (exposed by the ModelController) to register/unregister notification handlers * add NotificationSupport to emit notifications during a managemenet operations (through OperationContext.emit(Notification)) Notifications emitted by OperationContext.emit(Notification) are effectively sent at the end of the operation execution if it is successful. This ensure that the order of notifications emitted by a single OperationContext will be received in the same order (unless they are emitted during the ResultHandler execuion). If the NotificationSupport is created with an ExecutorService, the delivery of notifications is non-blocking and will not block the remaining code path of the operation execution. JIRA: https://issues.jboss.org/browse/WFLY-266 9.x PR: wildfly/wildfly-core#23
* add notifications to AS7 resources description notifications are described in :read-resource-description operation if the notifications boolean is true * NotificationDefinition let any resources describe the notifications they can emit by registering them in the ManagementResourceRegistration * add NotificationRegistry (exposed by the ModelController) to register/unregister notification handlers * add NotificationSupport to emit notifications during a managemenet operations (through OperationContext.emit(Notification)) Notifications emitted by OperationContext.emit(Notification) are effectively sent at the end of the operation execution if it is successful. This ensure that the order of notifications emitted by a single OperationContext will be received in the same order (unless they are emitted during the ResultHandler execuion). If the NotificationSupport is created with an ExecutorService, the delivery of notifications is non-blocking and will not block the remaining code path of the operation execution. JIRA: https://issues.jboss.org/browse/WFLY-266 9.x PR: wildfly/wildfly-core#23
* add notifications to AS7 resources description notifications are described in :read-resource-description operation if the notifications boolean is true * NotificationDefinition let any resources describe the notifications they can emit by registering them in the ManagementResourceRegistration * add NotificationRegistry (exposed by the ModelController) to register/unregister notification handlers * add NotificationSupport to emit notifications during a managemenet operations (through OperationContext.emit(Notification)) Notifications emitted by OperationContext.emit(Notification) are effectively sent at the end of the operation execution if it is successful. This ensure that the order of notifications emitted by a single OperationContext will be received in the same order (unless they are emitted during the ResultHandler execuion). If the NotificationSupport is created with an ExecutorService, the delivery of notifications is non-blocking and will not block the remaining code path of the operation execution. JIRA: https://issues.jboss.org/browse/WFLY-266 9.x PR: wildfly/wildfly-core#23
[WFCORE-1115 / JBEAP-1793]: Intermittent failures of CompositeOperationTestCase & CoreResourceManagementTestCase.
notifications are described in :read-resource-description operation if
the notifications boolean is true
they can emit by registering them in the ManagementResourceRegistration
notification handlers and emit notifications
Notifications emitted by OperationContext.emit(Notification) are
effectively sent at the end of the operation execution if it is
successful. This ensure that the order of notifications emitted by a
single OperationContext will be received in the same order (unless they
are emitted during the ResultHandler execuion).
JIRA: https://issues.jboss.org/browse/WFLY-266
This PR adds support for notifications to WildFly resources but does not add any (that'll be done in a later PR for WFLY-3603. The added tests shows how notifications can be defined and emitted and notification handler registered.
However, I already modified the tests that checks the resources operations and notifications. They'll be filled with assertions on the notifications as we add them.
This PR is for WildFly 9 so I added notifications support directly in the API (ModelController, ResourceDefinition). When we backport this feature for 8.2, I am not sure whether I can also modify directly the API or create subinterface.