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

[Jeff Mesnil]

On 07 Jul 2014, at 16:46, Jeff Mesnil <jmesnil at redhat.com> 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/