14 Replies Latest reply on May 23, 2005 3:29 PM by adrian.brock

    Dependency State Machine

      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

          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

            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

              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.

              • 4. Re: Dependency State Machine

                Thoughts?

                • 5. Re: Dependency State Machine
                  bill.burke

                   

                  "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

                     

                    "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

                       

                      "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

                         

                        "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

                           

                          "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

                            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

                               

                              "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

                                 

                                "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

                                   

                                  "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

                                     

                                    "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. :-)