"bstansberry(a)jboss.com" wrote : | 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. | Not sure I understand what you mean here. HASingletonSupport provides the notifications, not HASingletonController. HASingletonController just extends the start/stop singleton methods that are called by HASingletonSupport. In between the call to these methods, HASingletonSupport sends the notifications. HASingletonController, using the configured target methods, within start/stop singleton methods, calls them via the mbean server. I'm not sure how to do this cos I know little about MC, but any call to lifecycle methods (read singleton lifecycle) methods should really be done by the MC, shouldn't it? Other than that, HASingletonController just tells what are these methods. Maybe HASingletonController could just go? Maybe we could create @StartSingleton/@StopSingleton annotations and target beans could annotate such methods with these annotations. The MC then can call them. I might be talking absolute rubbish here though! :) How HASingletonSupport would instruct MC to do this is unknown to me. "bstansberry(a)jboss.com" wrote : | 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. | TODO1 for JBAS-4180 "bstansberry(a)jboss.com" wrote : | 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. | Hmmmm, I guess it'd make unit testing CP a lot easier if it didn't extend ServiceMBeanSupport? Other than that, I don't see it being used standalone to provide a non ServiceMBeanSupport extending version. "bstansberry(a)jboss.com" wrote : | 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. | Not a TODO of JBAS-4180 "bstansberry(a)jboss.com" wrote : | 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. | TODO2 for JBAS-4180, remove the findHAPartitionWithName method. What about whether DetachedHANamingService and HANamingService should extend ServiceMBeanSupport? "bstansberry(a)jboss.com" wrote : | anonymous wrote : | | + PingJndi | | ... | | | | ... Don't even know what PingJndi is. | Hidden gem maybe? hehehe ;) "bstansberry(a)jboss.com" wrote : | Thanks much for this. Even if we don't change much for 5.0.0 this is most helpful. no probs :-D View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091129#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...