Very quick response: Note the issue here is whether classes extend ServiceMBeanSupport, not whether they expose a JMX interface. Also, have a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118608 . Came up a couple weeks back. Showed me a benefit of subclassing ServiceMBeanSupport -- get to take advantage of the already coded methods that prevent duplicate lifecycle invocations when a MC bean is annotated with @JMX. "galder.zamarreno(a)jboss.com" wrote : | + Barrier, BarrierController, HASingletonController, HASingletonSupport and HAServiceMBeanSupport | | HASingletonController extends HASingletonSupport which sends notifications related to node becoming coordinator, or node stopping being coordinator. BarrierControler is the listener of these notifications, who's job is to start/stop of dependant services. Barrier is wrapper around the dependant service, which is started/stopped upon BarrierController's command via lifecycle methods. | | 1. BarrierController listens for JMX notifications, so should probably remain the same. Does not seem to make much sense to have JMX pulled out because it's its core business. Makes sense anonymous wrote : | 2. Whether Barrier should be JMX aware is debatable. Extends ServiceMBeanSupport directly and does little more. It's a mere delegator. No opinion. Not a priority either way. anonymous wrote : | 3. HASingletonController does nothing JMX related, except publicise (via getters) the configuration options for target start/stop methods. Needs JMX factoring out IMO. | The barrier counts on the notifications, and other users may be counting on the notifications as well, so if there is a refactoring to provide a non-JMX version, the std HASingletonController class needs to provide the notifications. anonymous wrote : | 4. HASingletonSupport knows when a node is coordinator or not, and via its parent, sends JMX notifications (only local notifications). HAServiceMBeanSupport can send JMX notifications locally or broadcast them accross the cluster. Both rely heavily on JMX functionality, so could stay the same. | 5.- 5.- JBAS-3982 should take in account the decision on HAServiceMBeanSupport, which provides infrastructure for cluster wide notifications" | Sounds right. anonymous wrote : | + HASingletonElectionPolicyBase and HASingletonElectionPolicySimple | | This is new functionality to decide where to run HA singleton services instead of the coordinator. It makes sense to factor JMX out of these classes to separate functionality from any JMX managed methods. An election policy should be independent, like the load balance policies. | +1. anonymous wrote : | + FarmMemberService | Ignore this. anonymous wrote : | + ClusterPartition | | Does not make sense to have a non JMX version. | Sure it does. Again, the issue here is whether classes extend ServiceMBeanSupport, not whether they expose a JMX interface. That said, changing this isn't a priority. anonymous wrote : | + UnifiedInvoker and UnifiedInvokerHA | | I'm not going to discuss legacy invokers here because they should remain as they are for backwards compatibility. To discuss JMX factoring out, let's focus on the unified invokers. | +1. anonymous wrote : | To factor out JMX from invokers makes sense to help unit testing and potentially make path for them to be migrated to Remoting (there's a JIRA on this) and be used standalone. It would also make my life a lot easier unit testing JBAS-4455 :) | Sadly, unlikely to happen before beta3 and thus not in 5.0.0. In any case, this should be driven by what's done with the non-HA version. anonymous wrote : | + DetachedHANamingService and HANamingService | | DetachedHANamingService uses JMX (via Query) to find an HAPartition with a given name via findHAPartitionWithName method. Couldn't find any references to this method and it's not a managed method either. That method should be removed; the partition should be dependency injected. I'm quite sure it already is injected; that method is probably just leftover cruft. anonymous wrote : | + HASessionStateService | | This looks like legacy code, so no need to touch it? | | + PingJndi | | Once again, legacy code? | +1 to ignoring both. Don't even know what PingJndi is. anonymous wrote : | Thoughts? Comments? Bored? :) Bored ;-) Thanks much for this. Even if we don't change much for 5.0.0 this is most helpful. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090828#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...