On 07 Jul 2014, at 16:46, Jeff Mesnil <jmesnil(a)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
Part 3: Global Resource Notifications
=> done in WFLY-3603
Part 5: Domain Notifications
=> code to emit notifications in domain mode is trivial 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
* 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
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
=> 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
=> 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
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.
JBoss, a division of Red Hat