The only reason this is there is it was there in Brian's original draft. I think I'd like to remove it for now

On 6/16/16 8:42 AM, Kabir Khan wrote: The reason for this is just that the only reason to receive a notification is to in turn take some action. So unless whatever they want to do has nothing to do with the rest of the system, they must: 1) Update the state of the MBeanServer, affecting JMX domains other than jboss.as[.expr]. This kind of thing is what was specifically mentioned by users in some of the discussions that led to this. 2) Take some action affecting the management resources, either via the ModelController or via the jboss.as[.expr] mbeans. Perhaps deploy something or... 3) Hack at MSC services via something like CurrentServiceContainer. 4) Update some state stored in static fields, which can then be read by other code of theirs that has access to the field. I think it's ok to not support 2) for now; we can see if people ask for it with a concrete use case. That said I think it's not good if we can't support it by making these notifications truly asynchronous to the operation that spawns them. Not providing a ModelControllerClient isn't going to block people using the jboss.as[.expr] mbeans, so the problem still exists, it's just more hidden. We don't want people doing 3) as its not a supported API. People who want to do that should write a subsystem. Same with 4) although at least there they aren't hacking our code, just their own. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

Correct, just an easier/nicer way to register in-vm notifications