On 4 Aug 2014, at 14:51, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
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)
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?
* 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
wildfly-dev mailing list