14 Replies Latest reply on May 23, 2005 3:29 PM by Adrian Brock

    Dependency State Machine

    Adrian Brock Master

      I've been looking at tidying up the dependency model
      used by the Microcontainer

      1) So that is easier to follow (e.g. currently you have to look at both the metadata
      and dependency item to see how it works)
      2) To make it more pluggable

      What I've actually been thinking about is that the dependency state machine
      should not by itself be tied to the bean model (BeanMetaData).
      The reason it is, was to follow the model used by the JMX microcontainer with
      translation MBean -> javabean

      Instead, the way I think it should it work is that the Controller should just allow
      an install of any MetaData object with the MetaData object interpreting what the
      lifecycle operations means.

      The only real requirement from the Controller is that the MetaData can "self
      describe" at which state dependencies are required, that those dependencies
      can be uniquely identified and that the "Instantiate" action gives a reference to
      some object.

      It is not even a requirement that the object go into the KernelRegistry.

        • 1. Re: Dependency State Machine
          Adrian Brock Master

          In more concrete terms, the Controller should have a

          ControllerContext install(MetaData)


          The MetaData gives a stateless callback for the lifecycle actions that are
          currently hardwired towards BeanMetaData at the moment

          public interface ControllerAction
          {
           void install(ControllerState state, ControllerContext context) throws Throwable;
           void uninstall(ControllerState state, ControllerContext context);
          }
          


          The BeanMetaData would just provide a callback that are the actions that
          are currently in AbstractController.

          • 2. Re: Dependency State Machine
            Adrian Brock Master

            This has one major advantage in terms of backwards compatiblity.

            Which is that it will work equally as well with the current JMX kernel ServiceContext,
            where the ServiceContext can provide callbacks that just do what the
            ServiceCreator/Configurator/Controller do now.

            In other words, running older JMX code with new POJO code won't require
            complicated JMX introductions/AOP proxies that Bill is reluctant to support.
            The JMX introduction will of course still be required to actually manage POJOs,
            but it would mean I can make a start on the JBoss5 integration without waiting for it.

            • 3. Re: Dependency State Machine
              Adrian Brock Master

              It can also be used to support other models, e.g. where Bill is dragging his heels
              deploying AOP metadata as BeanMetaData and instead using the POJO MC
              as a ServiceLocator.

              By removing the BeanMetaData requirement, this pattern can be more easily incorported
              without the cruft of wrapping things in BeanMetaData just to get the dependencies to work.

              • 5. Re: Dependency State Machine
                Bill Burke Master

                 

                "adrian@jboss.org" wrote:
                In other words, running older JMX code with new POJO code won't require
                complicated JMX introductions/AOP proxies that Bill is reluctant to support.


                Please expand on what I'm reluctant to support here...I have proxy support implemented and tested. These proxies also support introductions.



                • 6. Re: Dependency State Machine
                  Bill Burke Master

                   

                  "adrian@jboss.org" wrote:
                  It can also be used to support other models, e.g. where Bill is dragging his heels
                  deploying AOP metadata as BeanMetaData and instead using the POJO MC
                  as a ServiceLocator.

                  Please expand what you want explicitly and what exactly is missing instead of just insulting me.


                  • 7. Re: Dependency State Machine
                    Adrian Brock Master

                     

                    "bill.burke@jboss.com" wrote:
                    Please expand on what I'm reluctant to support here...I have proxy support implemented and tested. These proxies also support introductions.


                    You were (are?) reluctant to support a proxy that does not require any form of
                    bytecode manipulation, i.e. no use of aopc, runtime manipulation or javassist proxy
                    construction.

                    I couldn't get your tests to run, I "fixed" a few obvious things but then gave up.

                    Did you forget to commit something? :-)
                    http://sourceforge.net/mailarchive/message.php?msg_id=11771381
                    http://sourceforge.net/mailarchive/message.php?msg_id=11771375
                    + some others

                    • 8. Re: Dependency State Machine
                      Adrian Brock Master

                       

                      "bill.burke@jboss.com" wrote:
                      "adrian@jboss.org" wrote:
                      It can also be used to support other models, e.g. where Bill is dragging his heels
                      deploying AOP metadata as BeanMetaData and instead using the POJO MC
                      as a ServiceLocator.

                      Please expand what you want explicitly and what exactly is missing instead of just insulting me.


                      I am not insulting you, at least that was not my intension.
                      I'm sorry if you interpreted it that way.

                      I am actually agreeing with you. If you want to take it incrementally and use
                      the dependencies as a ServiceLocator we should support that as a first class notion.
                      You shouldn't have to do unnatural things to make this work.

                      The "Dragging Heels" comment refers to originally we agreed that the aspect
                      factories would be deployed as beans through the kernel, but this isn't what you are
                      doing now.

                      Somewhere down the road, the aspect manager will support DI and be integrated
                      with the full dependency model. In the meantime we need the ability to query
                      dependencies and use the service locator pattern.

                      To fully clarify before you misinterpet :-).
                      By the "aspect manager will support DI", I mean the aspect metadata will be injected
                      into the aspect manager as the aspect's dependencies are satisfied.

                      Currently the aspect is placed in the aspect manager's "holding area" where
                      anybody could activate "by reference" before the dependencies are satisfied.

                      • 9. Re: Dependency State Machine
                        Bill Burke Master

                         

                        "adrian@jboss.org" wrote:
                        "bill.burke@jboss.com" wrote:
                        Please expand on what I'm reluctant to support here...I have proxy support implemented and tested. These proxies also support introductions.


                        You were (are?) reluctant to support a proxy that does not require any form of
                        bytecode manipulation, i.e. no use of aopc, runtime manipulation or javassist proxy
                        construction.


                        I'm pretty sure Javassist proxy construction would work inside of an Applet as Chiba has some RMI proxy generation stuff and demos where it runs inside an applet, not sure about J2ME though. I don't understand why you just cannot use the Javassist Proxy construction stuff that's there now and then use the java.lang.reflect.Proxy implementation when it is complete. It should just be a method change.

                        BTW, I don't understand why you even need AOP/proxies anyways to support older JMX stuff within the new Kernel.



                        • 10. Re: Dependency State Machine
                          Adrian Brock Master

                          What I'm suggesting on this thread, is that is shortsighted to expect
                          only "beans" to take part in the dependency mechanism.

                          Instead, the dependency mechanism should be generalized
                          depending upon the model being used.

                          Beans: instantiate/configure -> kernel registry
                          MBeans: instantiate/configure -> MBeanServer
                          Aspects: instantiate/configure -> AspectManager
                          etc.

                          Each model is responsible for determining what the lifecycle operations
                          describe, instantiate, configure. create, start, install
                          means in its context.

                          The other advantage is that this gives the old MBean style deployments
                          a DESCRIBE state which means they are enhanced with the extra classloading
                          dependencies.

                          • 11. Re: Dependency State Machine
                            Adrian Brock Master

                             

                            "bill.burke@jboss.com" wrote:

                            BTW, I don't understand why you even need AOP/proxies anyways to support older JMX stuff within the new Kernel.


                            I know, that is why we keep arguing about it :-)

                            Fundamentally, I don't want to use the old JMX container with its own invocation model.
                            I want a new JMX container that uses the AOP invocation model (but not its bytecode manipulation). If bytecode manipulation has already been done on the MBean
                            then we should use it (it potentially allows extra functionality like MBean Attributes
                            based directly on private fields, i.e. without get/set), but this should not be a requirement - it is a "value add".

                            • 12. Re: Dependency State Machine
                              Bill Burke Master

                               

                              "adrian@jboss.org" wrote:
                              "bill.burke@jboss.com" wrote:
                              "adrian@jboss.org" wrote:
                              It can also be used to support other models, e.g. where Bill is dragging his heels
                              deploying AOP metadata as BeanMetaData and instead using the POJO MC
                              as a ServiceLocator.

                              Please expand what you want explicitly and what exactly is missing instead of just insulting me.


                              I am not insulting you, at least that was not my intension.
                              I'm sorry if you interpreted it that way.

                              I am actually agreeing with you. If you want to take it incrementally and use
                              the dependencies as a ServiceLocator we should support that as a first class notion.
                              You shouldn't have to do unnatural things to make this work.


                              I'm not understanding you.


                              The "Dragging Heels" comment refers to originally we agreed that the aspect
                              factories would be deployed as beans through the kernel, but this isn't what you are
                              doing now.


                              This is exactly what I am doing now. Take a look at the AspectSchemaFactory.



                              Somewhere down the road, the aspect manager will support DI and be integrated
                              with the full dependency model. In the meantime we need the ability to query
                              dependencies and use the service locator pattern.

                              To fully clarify before you misinterpet :-).
                              By the "aspect manager will support DI", I mean the aspect metadata will be injected
                              into the aspect manager as the aspect's dependencies are satisfied.

                              Currently the aspect is placed in the aspect manager's "holding area" where
                              anybody could activate "by reference" before the dependencies are satisfied.


                              Not true. A delegator is placed in the aspect manager's "holding area". This delegator looks up the actual factory within the Kernel when needed. If the factory does not have all dependencies satisfied, it will not be in the Kernel registry and the delegator will fail to create the aspect and throw an exception.

                              There has to be some locator pattern used somewhere as aspectized classes can be created with the new() operator. Either you locate the factory within the AspectManager or the kernel.


                              • 13. Re: Dependency State Machine
                                Adrian Brock Master

                                 

                                "bill.burke@jboss.com" wrote:

                                There has to be some locator pattern used somewhere as aspectized classes can be created with the new() operator. Either you locate the factory within the AspectManager or the kernel.


                                Agreed. I am saying eventually it will be in the DI, I'm not asking you to do this now.

                                • 14. Re: Dependency State Machine
                                  Adrian Brock Master

                                   

                                  "bill.burke@jboss.com" wrote:
                                  "adrian@jboss.org" wrote:
                                  "bill.burke@jboss.com" wrote:
                                  "adrian@jboss.org" wrote:
                                  It can also be used to support other models, e.g. where Bill is dragging his heels
                                  deploying AOP metadata as BeanMetaData and instead using the POJO MC
                                  as a ServiceLocator.

                                  Please expand what you want explicitly and what exactly is missing instead of just insulting me.


                                  I am not insulting you, at least that was not my intension.
                                  I'm sorry if you interpreted it that way.

                                  I am actually agreeing with you. If you want to take it incrementally and use
                                  the dependencies as a ServiceLocator we should support that as a first class notion.
                                  You shouldn't have to do unnatural things to make this work.


                                  I'm not understanding you.


                                  The "Dragging Heels" comment refers to originally we agreed that the aspect
                                  factories would be deployed as beans through the kernel, but this isn't what you are
                                  doing now.


                                  This is exactly what I am doing now. Take a look at the AspectSchemaFactory.



                                  Somewhere down the road, the aspect manager will support DI and be integrated
                                  with the full dependency model. In the meantime we need the ability to query
                                  dependencies and use the service locator pattern.

                                  To fully clarify before you misinterpet :-).
                                  By the "aspect manager will support DI", I mean the aspect metadata will be injected
                                  into the aspect manager as the aspect's dependencies are satisfied.

                                  Currently the aspect is placed in the aspect manager's "holding area" where
                                  anybody could activate "by reference" before the dependencies are satisfied.


                                  Not true. A delegator is placed in the aspect manager's "holding area". This delegator looks up the actual factory within the Kernel when needed. If the factory does not have all dependencies satisfied, it will not be in the Kernel registry and the delegator will fail to create the aspect and throw an exception.


                                  I don't conceed these other points, because you haven't understood what I am talking about. As usual, I suspect the problem is we talking about different things. :-)