10 Replies Latest reply on Jun 3, 2005 4:07 PM by Adrian Brock

    Management Aspect

    Adrian Brock Master

      This is continuing the discussion started off-topic here:
      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=64673

      The question is how do you manage the state of beans through JMX.

        • 1. Re: Management Aspect
          Adrian Brock Master

          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
            Adrian Brock Master

            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
              Bill Burke Master

              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
                Scott Stark Master

                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
                  Scott Stark Master

                  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
                    Adrian Brock Master

                     

                    "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
                      Adrian Brock Master

                       

                      "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
                        Adrian Brock Master

                        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
                          Scott Stark Master

                          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
                            Adrian Brock Master

                            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.