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

[Brian Stansberry]

On 8/4/14, 8:51 AM, Jeff Mesnil wrote:
>
> 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

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.

> 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
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat