1 2 Previous Next 22 Replies Latest reply on Mar 23, 2005 7:30 PM by Bill Burke

    using the registry/ClassAdapter.getDependencies()

    Bill Burke Master

      I'm currently going to iterate and try to implement all the aspect factories and see if I can get a woven class to publish its aspect dependencies to the kernel. There's a few things I need to know:

      * When I need to create an aspect, how do I resolve it. Will it be in the registry if the dependencies have been resolved yet? If it will exist in registry when dependencies are NOT resolved, how do I determine if dependencies have been resolved or not?

      * ClassAdapter.getDependencies() is currently not called anywhere. I need to know where this method should go, or you need to add the integration of this to the kernel yourself.

      THanks,

        • 1. Re: using the registry/ClassAdapter.getDependencies()
          Adrian Brock Master

           

          "bill.burke@jboss.com" wrote:
          I'm currently going to iterate and try to implement all the aspect factories and see if I can get a woven class to publish its aspect dependencies to the kernel. There's a few things I need to know:

          * When I need to create an aspect, how do I resolve it. Will it be in the registry if the dependencies have been resolved yet? If it will exist in registry when dependencies are NOT resolved, how do I determine if dependencies have been resolved or not?


          It won't be in the registry if dependencies aren't resolved.
          It will be known to the controller regardless
           KernelRegistryEntry getInstalledContext(Object name);
          



          * ClassAdapter.getDependencies() is currently not called anywhere. I need to know where this method should go, or you need to add the integration of this to the kernel yourself.

          THanks,


          No, I didn't know how you were going to do this, or the ClassAdapter for
          that matter.
          It belongs in AbstractKernelController$AbstractDescribeAction
          and needs to update the context's dependency info:
           BeanMetaData metaData = context.getBeanMetaData();
           BeanInfo info = configurator.getBeanInfo(metaData);
           context.setBeanInfo(info);
           // HERE
          


          I currently hide the ClassAdapter inside the BeanInfo abstraction.

          If you can tell me what the api is I have no problem about doing it.
          It is little more than
          DepedencyInfo depends = context.getDependencyInfo();
          for (Object o : beanInfo.getDepedencies()) // ClassAdapter.getDependencies or whatever
           depends.addIDependOn(new AbstractDependencyItem(KernelControllerState.INSTANTIATE, o, metaData.getName(), KernelControllerState.INSTALLED));
          


          • 2. Re: using the registry/ClassAdapter.getDependencies()
            Bill Burke Master

            *on lookup question*

            So, I get access to the Kernel and then first lookup in the registry to see if Aspect is there. If it is not there, I look in the KernelController to see if it is currently in deployment mode. If it *does not* exist within the KernelController I throw an exception UNKNOWN_ASPECT if does exist in the KernelController I thrown an exception ASPECT_NOT_DEPLOYED or whatever...

            I can figure out from the testsuite how to get a reference to the Kernel? The Kernel should be the entry point into the entire system?

            *on ClassAdapter*

            I thought ClassAdapter.getDependencies would return a list of Strings? The List of Strings I can easily populate. Is this what you need for API clarification?

            ClassAdapter.getDependencies needs to happen before the bean is instantiated. So, the dependencies need to be added and resolved before the bean is instantiated. Is this possible?

            * I guess I also need to know how to plug in a ClassAdapterFactory. I don't see any hooks anywhere for this. I guess this would be a change in the AbstractKernelConfig and Kernel itself? If you want me to do this, I can probably figure it out.

            Bill

            What more exactly do you need from me?

            • 3. Re: using the registry/ClassAdapter.getDependencies()
              Adrian Brock Master

               

              "bill.burke@jboss.com" wrote:
              *on lookup question*

              So, I get access to the Kernel and then first lookup in the registry to see if Aspect is there. If it is not there, I look in the KernelController to see if it is currently in deployment mode. If it *does not* exist within the KernelController I throw an exception UNKNOWN_ASPECT if does exist in the KernelController I thrown an exception ASPECT_NOT_DEPLOYED or whatever...

              I can figure out from the testsuite how to get a reference to the Kernel? The Kernel should be the entry point into the entire system?


              You don't *get* anything it is pushed to you (IOC)
              We want the AspectManager to be deployed as a mc javabean (instead of an
              mbean - no changes required here).

              Then the jboss-aop.xml would be deployed either through the aspectized
              deployer or by direction installation of your metadata model.

              Currently you don't have a metadata model, but what we want to do is the
              equivalent of
              xml -> MC instantiation of AspectMetaData (using Alex's JBossXB)
              or somebody could construct it programmatically.

              This metadata deployment would then be installed on the controller
              including the dependency injection of the AspectManager and at
              AspectMetaData.create() it would install the metadata.

              This allows us to take parts of the AspectMetaData
              (like the aspect factories) and add injections to those
              e.g. the tx advice needs to be injected with the transaction manager,
              it can declare this in its bean description.

              • 4. Re: using the registry/ClassAdapter.getDependencies()
                Adrian Brock Master

                 

                "adrian@jboss.org" wrote:

                You don't *get* anything it is pushed to you (IOC)


                The alternative is to make the aspect factories into a KernelRegistryFactory
                such that the dependency mechanism uses the AspectManager like JNDI
                but then you lose the ability to inject into the aspect configuration.
                I don't see your aspect configuration, only which aspects are registered.

                • 5. Re: using the registry/ClassAdapter.getDependencies()
                  Adrian Brock Master

                   

                  "bill.burke@jboss.com" wrote:

                  * When I need to create an aspect, how do I resolve it. Will it be in the registry if the dependencies have been resolved yet? If it will exist in registry when dependencies are NOT resolved, how do I determine if dependencies have been resolved or not?


                  That is the microcontainer's job. i.e. don't instantiate services until the
                  dependencies (including advice dependencies) are satisfied.


                  • 6. Re: using the registry/ClassAdapter.getDependencies()
                    Bill Burke Master

                    No, no, and no...

                    This is not how we agreed how it would work and I really don't feel like walking through this again as we spent at least a day arguing through this stuff.

                    The ClassAdvisor controls when aspects are created, not the IoC container. AspectFactories have additional metadata (scope) on when and how many times they are created. Also, AOP has additional injected types that cannot be resolved through the IoC container and must be resolved by AOP when AOP decides to instantiate.

                    So, IoC container will inject dependecies into the aspect via the GenericBeanFactory. The AOP ClassAdvisor needs to be able to lookup these GenericBeanFactories so it can decide when the Aspect is created.

                    Also, aspect factories sometimes have no idea how to resolve dependencies until they are bound to the class they are weaving into. i.e SecurityDomain. Don't you remember going through this exercise?

                    Anyways, please just answer my questions so that I can continue working...

                    Bill

                    • 7. Re: using the registry/ClassAdapter.getDependencies()
                      Adrian Brock Master

                       

                      "bill.burke@jboss.com" wrote:

                      * ClassAdapter.getDependencies() is currently not called anywhere. I need to know where this method should go, or you need to add the integration of this to the kernel yourself.


                      I answered that in the other thread.

                      • 8. Re: using the registry/ClassAdapter.getDependencies()
                        Bill Burke Master

                        Also, JBoss AOP *has* a metamodel. The only metamodel it doesn't have is Aspect configuration stuff (the IoC metadata).

                        • 9. Re: using the registry/ClassAdapter.getDependencies()
                          Bill Burke Master

                          Another thing, the way it would work would be that the AspectDeployer would deploy GenericBeanFactories into the IoC Container programmatically. I need to be able to inherit from GenericBeanFactory to provide my own additonal metadata that the AspectFactory needs. (Scope).

                          So, I still need answers to:

                          1) How to plug in a ClassAdapterFactory. I may be able to figure this out myself, not positive.
                          2) I think I can figure out from your first response where to integrate ClassAdapter.getDependencies(), not positive.

                          Bill

                          • 10. Re: using the registry/ClassAdapter.getDependencies()
                            Adrian Brock Master

                             

                            "bill.burke@jboss.com" wrote:
                            No, no, and no...

                            This is not how we agreed how it would work and I really don't feel like walking through this again as we spent at least a day arguing through this stuff.


                            And we are talking about different things again.


                            The ClassAdvisor controls when aspects are created,
                            not the IoC container.

                            Correct

                            AspectFactories have additional metadata (scope) on when and how many times they are created. Also, AOP has additional injected types that cannot be resolved through the IoC container and must be resolved by AOP when AOP decides to instantiate.

                            The aspect factories require configuration/injection this is done by the MC.
                            The aop framework is then responsible for doing factory.create() to create
                            the advices.


                            So, IoC container will inject dependecies into the aspect via the GenericBeanFactory. The AOP ClassAdvisor needs to be able to lookup these GenericBeanFactories so it can decide when the Aspect is created.

                            These are injected into the AspectMetaData/AspectFactory/GenericBeanFactory,
                            not the aspect.
                            Currently this is not possible because jboss-aop.xml reads the xml and does the construction directly from it.


                            Also, aspect factories sometimes have no idea how to resolve dependencies until they are bound to the class they are weaving into. i.e SecurityDomain. Don't you remember going through this exercise?


                            Yes that is the @Dependency annotation:
                            @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
                            @Dependency(name="value") // HERE value() represents something to depend upon
                            public @interface SecurityDomain
                            {
                             String value();
                            }
                            


                            • 11. Re: using the registry/ClassAdapter.getDependencies()
                              Adrian Brock Master

                               

                              "bill.burke@jboss.com" wrote:

                              1) How to plug in a ClassAdapterFactory. I may be able to figure this out myself, not positive.


                              The bootstrap constructs a KernelConfig.

                              The KernelConfig has a getBeanInfo() which is what decides the ClassAdaptor
                              to use.

                              It is simply a case of replacing the AbstractKernelConfig with an implementation
                              that does more than ask for a Reflection based classadapter.


                              • 12. Re: using the registry/ClassAdapter.getDependencies()
                                Adrian Brock Master

                                 

                                "adrian@jboss.org" wrote:

                                e.g. the tx advice needs to be injected with the transaction manager,
                                it can declare this in its bean description.


                                This looks to have caused the confusion, I will reword it more precisely.

                                The GenericBeanFactory used by the AspectFactory for the tx advice
                                needs a TransactionManager injection.

                                • 13. Re: using the registry/ClassAdapter.getDependencies()
                                  Bill Burke Master

                                   

                                  "adrian@jboss.org" wrote:

                                  So, IoC container will inject dependecies into the aspect via the GenericBeanFactory. The AOP ClassAdvisor needs to be able to lookup these GenericBeanFactories so it can decide when the Aspect is created.

                                  These are injected into the AspectMetaData/AspectFactory/GenericBeanFactory,
                                  not the aspect.
                                  Currently this is not possible because jboss-aop.xml reads the xml and does the construction directly from it.


                                  This does not happen at deployment. The XML fragment in the aspect declaration in jboss-aop.xml is stored for later use when then aspect is actually created/instantiated. It is just a matter of writing a new AspectFactory implementation and plugging it in.



                                  Also, aspect factories sometimes have no idea how to resolve dependencies until they are bound to the class they are weaving into. i.e SecurityDomain. Don't you remember going through this exercise?


                                  Yes that is the @Dependency annotation:
                                  @Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME)
                                  @Dependency(name="value") // HERE value() represents something to depend upon
                                  public @interface SecurityDomain
                                  {
                                   String value();
                                  }
                                  


                                  This @Dependency annotation only tells the MC about the dependency. The MC doesn't know how/where this dependency should be injected. The @SecurityDomain is on the bean class and it is the aspect that needs this information to lookup and set the dependency within the aspect. A distinct, non-GenericBeanFactory implementation of an AspectFactory would be needed here. It would work the same way the Security aspect works now in the current impl except that they MC would be able to hold up bean creation because the SecurityDomain dependency would be published to it via the @Dependency annotation.


                                  • 14. Re: using the registry/ClassAdapter.getDependencies()
                                    Adrian Brock Master

                                    Just to round off the discussion and what I think we agreed.

                                    1) The MC will inject dependencies into GenericBeanFactories
                                    where advices need injections. These GBFs will be used by a generic
                                    aspect factory to construct the advices as required according to scope.

                                    2) The MC needs to know about the @Dependency annotations of the
                                    class and the relevent AspectFactories names so it can correctly workout the
                                    dependency order as it starts services.

                                    3) There will be an aspect deployer that does
                                    xml -> MC config to construct and install Aspect metadata
                                    instead of the AspectXMLLoader/Deployer
                                    The advice dependcies can be defined through
                                    a) annotations on the advice class using (2) above
                                    b) annotation overrides in the MC config
                                    c) plain MC depends xml config

                                    1 2 Previous Next