Emulating ServiceMBeanSupport

[genman]

ServiceMBeanSupport exposes methods stop, start, create, destroy. These are implemented to in turn call the ServiceController, which then calls jbossInternalLifecycle(), which then calls startService(), stopService(), etc. This means if somebody does a call to "stop", the controller state will be changed, dependent services will be stopped as well, etc. This is different than the Microcontainer which treats "stop" as a callback, "stop" will be called after state is changed.

In JBoss 5.0 some of the state management is handled by the Microcontainer. But a lot is still handled by the ServiceController.

What I would like to do is if have a POJO such as:

@Service
public class MyService {
 public void start() throws Exception { ... }
 public void stop() throws Exception { ... }
 public String getState() { return null; }
}

Currently,

start

is called by the Microcontainer, before the START controller state is reached.

If somebody (other than the Microcontainer) calls

MyService.stop()

, I'd like AOP to intercept this call and instead call the Microcontainer to handle the stop transition. I'm a newbie and not sure how to write this AOP declaration in the -beans.xml. Probably what I will have is an annotation (@Service ?) marking classes to apply this to.

When I write my Interceptor, how do I know if the Microcontainer is calling me due to Lifecycle transition, or the call is from "somebody else"?

I'd like to also intercept calls to the method "getState()" and return the Microcontainer state. Or, I'd like to "inject" state somehow.

public class MyService {
 @InjectState
 State state;
 public State getState() { return state; }
}

[alesj]

"genman" wrote:

I'd like to also intercept calls to the method "getState()" and return the Microcontainer state. Or, I'd like to "inject" state somehow.

public class MyService {
 @InjectState
 State state;
 public State getState() { return state; }
}

Just added new feature:

<inject fromContext="getState" />

will do the job. ;-)

Follow this post for more info:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=113340&start=20

[alesj]

"alesj" wrote:

Just added new feature:

<inject fromContext="getState" />

will do the job. ;-)

But this is useless, since you'll only get this injected at the whenRequired state - which you can 'tell' in advance. ;-)
Perhaps use one of the [State]KernelControllerContextAware interfaces to get the ref to underlying KernelControllerContext.

[alesj]

"genman" wrote:

In JBoss 5.0 some of the state management is handled by the Microcontainer. But a lot is still handled by the ServiceController.

All of the state management is handled by MC, ServiceController is just a facade over MC - see actual code for more details: http://anonsvn.jboss.org/repos/jbossas/trunk/system-jmx/src/main/org/jboss/system/ServiceController.java

[alesj]

"genman" wrote:

When I write my Interceptor, how do I know if the Microcontainer is calling me due to Lifecycle transition, or the call is from "somebody else"?

You can always check the current execution stack. :-)

[genman]

"alesj" wrote:

All of the state management is handled by MC, ServiceController is just a facade over MC - see actual code for more details: http://anonsvn.jboss.org/repos/jbossas/trunk/system-jmx/src/main/org/jboss/system/ServiceController.java

What I see doesn't seem to be a light facade. The old states are really independent from the new ones. The new ones don't match exactly to the old, which means the ServiceController has to track state separately in a ServiceContext object. There's a bit of book keeping involved. I could probably live with the new state list, though it's a little odd the state names don't correspond to the methods that are actually called during the transitions.

You can always check the current execution stack. :-)

[genman]

You can always check the current execution stack. :-)

This feels like a hack, hence the smiley ...

I might be better off creating a central service controller that users would use to stop/start services by name. Exposing stop/start as MBean operations seems logical, but if there isn't a clean way to detect who's calling stop(), I probably should avoid this approach.

Could you point me to some examples on how to construct a method interceptor in the -beans.xml format, for beans marked with annotations? In case I change my mind again.

<inject fromContext="getState" />

Also: Is there a way to inject "beaninfo" using annotations? I'd rather not have to copy the same injection XML for every declaration. :-)

[alesj]

"genman" wrote:

Could you point me to some examples on how to construct a method interceptor in the -beans.xml format, for beans marked with annotations? In case I change my mind again.

http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/docs/gettingstarted/src/docbkx/en/modules/aop.xml

"genman" wrote:

Also: Is there a way to inject "beaninfo" using annotations? I'd rather not have to copy the same injection XML for every declaration. :-)

<inject fromContext="beaninfo" />

The annotation support is just on its way.