The highlighted parts of my descriptor above show the bits I'm not clear about. And AttributeChangedNotification does not usually return a handback object ( I'm not 100% clear on this ) so I am not sure which values to use for StartBarrierHandback and StopBarrierHandback. I know I should look at the MasterNode or State attributes of my static singletonMBean...although the above does not work.

The issue here is, I don't think you can count on the AttributeValueChange (AVC) from your Scheduling service (that is if you extend ServiceMBeanSupport), because it's going to be started anyway when you deploy it.

The HASingletonController will invoke startSingleton/stopSingleton on your service, and you can emit a pair of notifications there to indicate this fact, then you intercept those in the BarrierController.

The hankback object is provided by whoever makes a subscription, to allow him to distinguish from which subscription a notification comes (because you can have many subscritpions). It has nothing to do with the Notification itself.

What I see here, this is a very good use case and if we make the HASingletonController emit alternatively notifications, rather than invoke callback (e.g. through a config option), we can then just attach a Barrier and have any number of mbeans to depend on that...