[jboss-dev-forums] [Design of POJO Server] - JBAS-5578 ServiceMBeanSupport as MC bean

bstansberry@jboss.com do-not-reply at jboss.com
Tue Jun 3 13:17:54 EDT 2008


Discussion of http://jira.jboss.com/jira/browse/JBAS-5578

Kind of an odd issue as it relates to doing something strange -- deploying a ServiceMBeanSupport subclass via a beans.xml, and then annotating it as @JMX.  The create/start/stop/destroyService methods don't get invoked. 

This comes up because I tend to try to deploy things as MC beans, but for backwards compatibility reasons things like HASingletonController are still ServiceMBeanSupport subclasses.  So I hit weird issues. I can work around them, so not critical. But want to bring it up in case it suggests some more fundamental problem.

Anyway, here's what I think is going on:

I think this has to do with ServiceControllerLifecycleCallback. The @JMX annotation means this class handles starting the service. Leads to this:

ServiceControllerLifecycleCallback.install --> ServiceController.start(ObjectName) --> ServiceController.doChange(controller, context, ControllerState.INSTALLED, "start")

does some stuff... and then calls into ServiceMBeanSupport.start() which has this:


  |       if (serviceName != null && isJBossInternalLifecycleExposed)
  |          server.invoke(ServiceController.OBJECT_NAME, "start", new Object[] { serviceName }, SERVICE_CONTROLLER_SIG);
  |       else
  |          jbossInternalStart();
  | 

The first branch of the if test is taken and that calls ServiceController.start(ObjectName) again (i.e. a recursive call).  That call hits this and returns:


  |       // If we are already started (can happen in dependencies) just return
  |       if (ctx.state == ServiceContext.RUNNING || ctx.state == ServiceContext.FAILED)
  |       {
  |          log.debug("Ignoring start request for service: " + ctx.objectName + " at state " + ctx.getStateString());
  |          return;
  |       }
  | 

Effect of all this is the startService() method never gets invoked.


One possible solution to this is to add a way to configure the bean (a setter) such that isJBossInternalLifecycleExposed returns false.  Avoid the recursive call.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155445#4155445

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155445



More information about the jboss-dev-forums mailing list