On 8/4/14, 8:51 AM, Jeff Mesnil 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[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.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat