HASingletonController can have the target bean directly injected, in which case it will not invoke the target's methods via JMX. Your comment about @StartSingleton, etc. is valid, but lets defer to a different discussion. Not going to happen for beta3. What does a class gain by subclassing ServiceMBeanSupport: 1) Benefits from the lifecycle coding. Stuff that prevents startService() being called again when service is already started, etc. 2) Support for exposing service lifecycle state as an mbean attribute (getState()) 3) I gets a ref to the mbean server when an instance is registered in JMX. Can use that to make JMX calls. 4) Probably others; part of task is to identify and see if relevant 1) and 2) are conceptually different from 3). Illustration: Class implements the lifecycle methods; deployed by MC as a pojo service. MC invokes lifecycle methods. In the -beans.xml the bean is annotated with @JMX. Sole purpose of this is to get the bean registered in JMX. Doing this is not a functional requirement of the class; it's a deployment decision for *that particular instance of the class*. MC will create a JMX proxy to the service and deploy that as well. When the proxy is deployed, the create/start/stop/destroy methods get called *again*. This is where benefit 1) is useful. You could get the same benefit by coding equivalent #1 functionality in the bean class itself, or in some PojoServiceSupport superclass. If the class needs to use the mbean server to do its work, then you start getting into benefit #3. You need a ref to the server. What I want here is the #3 cases isolated, particularly for the HASingletonController/HASingletonSupport. That class should be usable without it having a ref to an MBeanServer if: 1) user doesn't need the JMX notifications 2) user configures the deployment to dependency inject the target rather than injecting an ObjectName. 3) Other things you might find by digging. Don't worry about making DetachedHANamingService not extend ServiceMBeanSupport. It's the singleton stuff where I can imagine wanting to have a lot of deployment flexibility. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091148#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...