7 Replies Latest reply on Nov 11, 2006 11:04 AM by Kabir Khan

    onDemand handling and aspects

    Scott Stark Master

      For aspects like the jmx and jndi introductions that hook into the KernelControllerContextAware callbacks, who handles onDemand behavior? I believe Adrian indicated that these aspects really need to be honoring the onDemand behavior and not operating until the bean is requested. What is the callback that would have to be used in place of the KernelControllerContextAware interface?

        • 1. Re: onDemand handling and aspects
          Kabir Khan Master

          I am not sure. All I know is that Adrian mentioned that the KernelControllerContextAware interface is a temporary solution

          • 2. Re: onDemand handling and aspects
            Ales Justin Master

            From KernelControllerContextAware interface.

            * WARNING: This protocol is subject to change with the classadapter implementation.
            * @todo integrate better with aop and instance classadapter such that
            * describe can process this without the instance actually existing.
            * Use case: creating jmx/jsr77 hollow proxy for on-demand beans before they are instantiated.

            • 3. Re: onDemand handling and aspects
              Scott Stark Master

              The current required configuration also seems a bit forced in that the one has to introduce the KernelControllerContextAware and then check for the install/unistall psuedo lifecycle methods. It seems like we need a more naturual place to define annotations that should apply to install/uninstall a bean into the kernel once all its dependencies are satified with a base class removes the need to check whether the method is an install or uninstall event. I have not drilled too far into what the mc hooks are available in this area as yet.

              • 4. Re: onDemand handling and aspects
                Ales Justin Master

                I think this was what Adrian was talking about. Simplicity.
                I feel that there is too much verbose xml code to deal with to simply introduce JMX or Jndi registration.

                I have not drilled too far into what the mc hooks are available in this area as yet.

                Yep. Should discuss this at JBW - in my opinion. But should probably be Adrian's decision / idea - and our implementation.

                • 5. Re: onDemand handling and aspects
                  Kabir Khan Master

                  I am looking at reworking the AspectBeanMetaDataFactory to replace the Advice, Aspect and AspectBinding beans at least.

                  +1 on eliminating the need to introduce an interface, although this could probably be hidden by a BeanMetaDataFactory too.

                  • 6. Re: onDemand handling and aspects
                    Adrian Brock Master

                    The issue is more to do with the current KernelAware interface
                    not being rich enough because it only deals with the instance.

                    The callbacks are done on whether the instance (which could implement it
                    via an interceptor) has to be constructed.

                    What we really want is for all controller contexts to be acted upon
                    regardless of whether the real instance exists.

                    Such an api exists, it is the [Instance]ClassAdapter which was originally designed
                    to represent the instance regardless of whether it exists.

                    But the current code does not use the ClassAdapter exclusively so there is no
                    consistency. This was a deliberate decision in the AOP integration to
                    "get something working" without modifying AOP too much.

                    P.S. An alternative approach would be treat the JMX registration as a new deployer
                    that acts after the bean metadata. But this has no integration with the real AOP.

                    • 7. Re: onDemand handling and aspects
                      Kabir Khan Master

                      As part of http://www.jboss.com/index.html?module=bb&op=viewtopic&t=94575

                      I extended the AspectBeanMetaDataFactory so that instead of

                       <bean name="JMXIntroduction" class="org.jboss.aop.microcontainer.beans.IntroductionBinding">
                       <property name="classes">@org.jboss.aop.microcontainer.aspects.jmx.JMX</property>
                       <property name="interfaces">
                       <list elementClass="java.lang.String">
                       <property name="manager"><inject bean="AspectManager" property="aspectManager"/></property>
                       <beanfactory name="JMXAdvice" class="org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction">
                       <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>
                       <bean name="JMXAspect" class="org.jboss.aop.microcontainer.beans.Aspect">
                       <property name="advice"><inject bean="JMXAdvice"/></property>
                       <property name="manager"><inject bean="AspectManager" property="aspectManager"/></property>
                       <bean name="JMXBinding" class="org.jboss.aop.microcontainer.beans.AspectBinding">
                       <property name="pointcut">execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))</property>
                       <property name="aspect"><inject bean="JMXAspect" property="definition"/></property>
                       <property name="manager"><inject bean="AspectManager" property="aspectManager"/></property>

                      we can use
                       <aop:lifecycle xmlns:aop="urn:jboss:aop-beans:1.0"
                       pointcut="execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))">
                       <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>

                      It is definitely easier and less verbose, but I did this before I saw Adrian's reply, which I have yet to digest :-)