org

* Refactor the registry for the notification handlers by splitting the map

into path segments to mitigate the o(n) cost.

* Rename the registry to NotificationHandlerRegistry and move it to the

org.jboss.as.controller.registry package (leveraging the

AtomicFieldUdpated of the package too)

JIRA: https://issues.jboss.org/browse/WFLY-266

9.x PR: https://github.com/wildfly/wildfly-core/pull/95

* Emit JMX notifications based on WildFly's own notifications

* Notification is supported for JMX connections either in-vm (through

ManagementFactory.getPlatformMBeanServer() or WildFly's

MBeanServerService) and remotely if the JVM is started with the remote

monitoring and management

* WildFly remoting-jmx does not support JMX notifications

* WildFLy notification are converted to their idiomatic JMX

counterpart

* WildFly's attribute-value-written is converted to JMX's

AttibuteChangeNotification

* WildFly's resource-added and resource-removed are converted to JMX's

MBeanServerNotifications *and* emitted by the

MBeanServerDelegateMBean (like regular MBeans)

JIRA: https://issues.jboss.org/browse/WFLY-3169

9.x PR: https://github.com/wildfly/wildfly-core/pull/82

Whilst the OperationContext made a good candidate for holding some of this as soon as interaction with non-management components occurred this state was no longer accessible.

The use of a ThreadLocal here uses the Subject.doAs stye so we can ensure any previous context is cleared as the call returns up the stack.