6 Replies Latest reply on Feb 4, 2006 9:27 AM by Adrian Brock

    JBMICROCONT-18

    Kabir Khan Master

      I've started taking a look at the microcontainer, as I have been assigned this JIRA task. While what's been done for org.jboss.aop.microcontainer.prototype.* makes sense, it is not clear to me what I should be doing for this task.

      Is what we are after something similar to the existing annotation overrides? If not can we flesh out what is needed here a bit so I can get started?

        • 1. Re: JBMICROCONT-18
          Adrian Brock Master

          There are a number of issues. This is just the one that is in the MC project.
          The others are against aop in JIRA.

          Let me re-iterate the proxies work then I'll come back to annotations.

          • 2. Re: JBMICROCONT-18
            Adrian Brock Master

            So proxies/advised pojos.

            The requirement here is to be able to advise a POJO at instance level
            (to override annotations/metadata - see later) for this instance.

            My main requirement is to advise the POJO using a sort of Introduction
            that acts upon the Microcontainer lifecycle to do extra work for the POJO
            during deployment. I call these "Decorations" in another thread.

            See the JMXIntroduction test in the aspects project for a more complete test.

            My prototype isn't very good because it requires you to wrap the POJO
            for all methods, i.e. runtime exceptions even though these might not be advised.
            It also doesn't support "hollow instances" - see below about "On Demand".

            There are a number of possible circumanstances to support:
            1) Unadvised -> Just use the object
            2) Already AOP advised with no instance metata -> use the aop advisor
            3) Already AOP advised with instance metadata -> need an instance advisor
            4) Not AOP advised - need to add an advisor (either class or instance)
            4a) Just Microcontainer lifecycle advices - only this part is advised
            4b) Other runtime advices - the whole object is advised

            I differentiate Microcontainer advices and the normal advices because
            the MC needs the ability to advise the abstract notion of the instance,
            i.e. before the object is instantiated.

            More concretely, lets take the case where the user wants to trigger JMX for the MC
            with "On Demand". The idea being we create and register an MBean for the
            instance that does not exist, then when somebody clicks "start" it actually
            creates the real object.

            <bean name="Foo" mode="On Demand">
             <annotation name="JMX"/>
            </bean>
            


            This will add the KernelControllerContextAware Introduction
            which the JMX advice processes by (un)registering an MBean wrapper.

            When the user clicks start, the MBean calls back onto the KernelControllerContext
            to actually install the object.
            Obviously, this advice shouldn't apply on the normal methods the POJO.

            Feel free to ask questions, I haven't gone into the advised/nonadvised proxy
            debate. Bill and I have gone over this endlessly with the argument always
            boiling down to:

            Bill: I think AOP can do what you want all environments
            Adrian: Prove it, e.g. make it work in an applet (acid test)
            Bill: We need to do this in steps, I can't do everything straight away
            Adrian: OK
            Bill: But I'm working on EJB3 anyway :-)

            • 3. Re: JBMICROCONT-18
              Adrian Brock Master

              For annotations the idea is come up with a common model.

              The sources of annotations will be
              * The class
              * aop deployment info
              * microcontainer config
              * The metadata service that Scott is prototyping

              This should all got merged into a single view, that provides type safe metadata.
              Most commonly this will be used from the SimpleMetaData in Invocation
              but not exclusively, e.g. management apps will want to look at/configure this
              externally.

              If you look at JMXIntroduction, it is just using the MC metadata directly.

              There is a sort of shell for this in the ClassInfo abstraction in the container module.

              I think this also links into "retroweaving" where we want to backport code
              written with JDK5 onto JDK1.4

              If somebody does

              MyClass.class.getAnnotation(MyAnnotation.class)
              

              this would be weaved to something like
              MetaDataRepository.getAnnotation(MyClass.class, MyAnnotation.class)
              


              Additionally, we need to examine annotations that introduce dependencies,
              such that these can be added to the MC context for correct deployment.

              e.g.
              @SecurityDomain("MyRealm");
              public class MyClass {}
              


              Would have meta annotations on SecurityDomain that says
              MyRealm is a dependency. i.e. This class needs the security domain
              in an installed state before it is installed.

              The overall protocol is roughly outlined in the describe/instantiate part of the MC's
              KernelControllerContextActions.
              It uses the ClassAdapter as a kind of notion of class/instance that doesn't
              yet exist.

              The ClassAdapter is actually hidden behind the BeanInfo objects.
              This is because the BeanInfo can change if the extra annotations
              add new interfaces/methods.

              Pseudo code:
              Describe:
              BeanInfo info = BeanInfoFactory.getBeanInfo();
              addMicrocontainerAnnotations(info); // This does not exist - JBMICROCONT-18
              ControllerContext.addDependencies(info.getDependencies()); // info.getDependencies() doesn't do anything either currently.
              
              Instantiate:
              Joinpoint jp = getConstructorJoinpoint(beanInfo, ....);
              jp.dispatch();
              


              The *gotcha* is that getConstructorJoinpoint could return a method
              invocation, if it is on a factory, e.g. a singleton.
              It is the factory's responsibility to control/configure the object, we can't really
              add annotations to an object that somebody else constructs (except through
              normal AOP config).

              • 4. Re: JBMICROCONT-18
                Adrian Brock Master

                Like it says in the Microcontainer documentation.
                http://docs.jboss.org/nightly/microkernel/docs/reference/en/html/

                The current api:
                * Reflection Model: ClassInfo
                * Integration: ClassAdapter
                * Joinpoint
                * JavaBean model - BeanInfo

                Is considered unstable.

                It can morph (or change enitrely) if we think there
                is a better way to integrate the Microcontainer and AOP.

                I'm not very happy with the way Bill's or my prototype determine the
                AspectManager/Domain to use.
                This would be better expressed through the metadata context of the
                application/deployment.

                i.e. This application/subsystem uses this Domain for its AOP config.

                e.g. separate domains for JBoss Messaging, EJB3, JCA advices.

                Bill sort of has some of this idea in EJB3, but I can't say I have looked
                too deeply at it.

                • 5. Re: JBMICROCONT-18
                  Adrian Brock Master

                  The first things we need to get this working is the Microcontainer
                  being able to use the real AOP instance proxy advisors
                  and we need to share the annotation model.
                  i.e. drop my prototype

                  Some of the edge cases and things like linking to Scott's metadata repository
                  or dependencies from the annotations can come later.

                  Even using a single AOP domain (the AspectManager.getInstance())
                  is ok to start with.

                  We just need to keep the future requirements in mind when designing the
                  api we will use to communicate with each other.

                  And correctly separate our concerns. e.g. I shouldn't need to know
                  in the Microcontainer much about how the invocation or metadata context works.
                  The Microcontainer will only be involved in this when it populates it,
                  i.e. it is just like configuring any other service.

                  • 6. Re: JBMICROCONT-18
                    Adrian Brock Master

                     

                    "adrian@jboss.org" wrote:

                    i.e. drop my prototype


                    Also my prototype sucks big time.
                    After a couple of other optimizations in AOP, a stress test for creating and using
                    an instance proxy shows it spending something like 90+% of its initializing the
                    ClassContainer.

                    Most of this time is spent matching method pointcuts.