-
1. Re: Management Aspect
First let's look at how ServiceMBeanSupport does this.
When the user clicks "stop" on the jmx-console this invokes
mbean.stop()
which is implemented by ServiceMBeanSupport.
This is redirected to the ServiceController
controller.stop(mbeansObjectName)
which allows the service controller to stop dependent services
before this one is stopped.
Once the dependents are stopped,
the ServiceController calls back into the MBean to stop it.
mbean.internalLifecycle("stop");
which invokes
mbean.stopService();
So the lifecycle functions on the mbean are really processed by
the ServiceController. -
2. Re: Management Aspect
The proposol for the POJOs in the new microcontainer is to
add an "Introduction" that gives the pojo a DynamicMBean interface
such that it can be registered with the JMX MBeanServer.
Whether this really is an introduction (i.e. we add the interface to the POJO)
or just a proxy in front, is irrelevent to this discussion.
There's already a couple of implementations of this, e.g.
@MBean in aspects
Some attic code in kernel
StandardMBean in jmx
From this, we can expose MBean operations to control the bean's state
in a similar manner to the ServiceMBeanSupport above, without having
the POJO know anything about JMX or that it is under the control of the MC. -
3. Re: Management Aspect
My EJB extensions also have the concept of a @Service. A @Service can expose both a remote, local, and JMX management interface.
Come to think of it, the @Mbean might be kinda stupid...You already said we have StandardMBean, and isn't there already some utility that can take any Java class and generate MBeanInfo so that we can create a Model MBean from a POJO? So, although @MBean was a good test of an AOP introduction, its probably not needed?
Don't know....I do like the @Service because it requires no DDs and can have more than just a JMX interface. -
4. Re: Management Aspect
I was looking for where the management aspect gets introduced in the referenced thread, not how state is manipulated via jmx. Today, existence of a jmx interface is manifest when the service instance is created by the SARDeployer.
What I am still missing is who is doing the MBeanServer.registerMBean() given the DynamicMBean introduction, and at what point in the lifecycle is this done? -
5. Re: Management Aspect
The more general question I am driving at, is how do the aspects of a component interact with the component container lifecycle states. Ignoring my abuse of aop terminology, it would seem that we need the notion of introductions on the life-cycle joinpoints (that is, state transitions). The analog for the legacy jmx kernel is that I would have to deploy the component as an xmbean and have interceptors that caught the Service method invocations.
-
6. Re: Management Aspect
"scott.stark@jboss.org" wrote:
The more general question I am driving at, is how do the aspects of a component interact with the component container lifecycle states. Ignoring my abuse of aop terminology, it would seem that we need the notion of introductions on the life-cycle joinpoints (that is, state transitions). The analog for the legacy jmx kernel is that I would have to deploy the component as an xmbean and have interceptors that caught the Service method invocations.
Yes, the interceptors/advice are my preferred solution to this. Though we have
discussed in the past having a KernelAware interface.
I haven't done KernelAware because I don't want to encourage people
writing POJOs that depend upon the Kernel API. -
7. Re: Management Aspect
"scott.stark@jboss.org" wrote:
What I am still missing is who is doing the MBeanServer.registerMBean() given the DynamicMBean introduction, and at what point in the lifecycle is this done?
The answer to this question is that it is domain specific (i.e. the advice will work
in different ways).
For a pure POJO MC that just wants to expose objects for management
through an MBeanServer it is better to do this at "INSTALL".
For compatibility with the JMX MC, i.e. within JBoss itself, the registeration will
likely need done during the INSTANTIATE phase because the
JMX MC assumes JMX registration at an early stage.
I notice you recently fixed the MBeanProxy injection to allow for more lazy
initialization, but I don't think that fully resolves this problem. -
8. Re: Management Aspect
So putting this together, the solution will be to have a KernelAware
interface, but actually implement what this means in the Advice, not the POJO. -
9. Re: Management Aspect
Do you have a psuedo syntax for an xml deployment specification of say MyPojo, with LegacyJMXLifecycleAdvice where LegacyJMXLifecycleAdvice would be the implementation we provide that behaves similar to the existing mbean services? Assume the DynamicBean interface can be gleaned from the java bean view of MyPojo. No, this is not a test.
-
10. Re: Management Aspect
You would add an @MBean annotation or whatever we want to call it.
<bean> <annotation name="org.jboss.aspects.jmx.MBean"/> </bean>
The the pointcut expression determines what advice gets injected.<interceptor class="org.jboss.aspects.jmx.LegacyJMXLifecycleAdvice" scope="PER_VM"/> <bind pointcut="execution(* @org.jboss.aspects.jmx.MBean->*(..))"> <interceptor-ref name="org.jboss.aspects.jmx.LegacyJMXLifecycleAdvice"/> </bind>
That way @MBean has a logical meaning that it is implemented by the aop config.
It could even be NOOP if there is no aop definition.