1 2 Previous Next 22 Replies Latest reply on Mar 23, 2005 7:30 PM by bill.burke Go to original post
      • 15. Re: using the registry/ClassAdapter.getDependencies()

         

        "bill.burke@jboss.com" wrote:

        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.


        Correct, the @SecurityDomain tells the MC the correct order for instantiation.
        The advice does not change its implementation. I think this is a major requirement.
        i.e. none of our changes should affect user code already in existance.
        What we are changing (hopefully improving) is the way and the possiblities
        they are configured/managed.

        In the security domain case, it will still use jndi as now, though as Scott pointed
        out in a different thread, the implementation could be improved to avoid the dependency on jndi.

        • 16. Re: using the registry/ClassAdapter.getDependencies()

           

          "adrian@jboss.org" wrote:
          In the security domain case, it will still use jndi as now, though as Scott pointed
          out in a different thread, the implementation could be improved to avoid the dependency on jndi.


          In the same vain, the TX aspect can be improved to avoid the
          TxManager.getInstance() and use dependency injection instead.

          This is an especially important requirement when the aspects are being used
          as an integration layer across different app servers by our services.

          The MC or some trivial factory controlled by the MC
          knows the TM instance or how to map a security domain/realm
          to the platform's native notion.

          • 17. Re: using the registry/ClassAdapter.getDependencies()
            bill.burke

            phew cool...I was scared from your previous post that we had to have the same argument all over again.. :) *blush*

            So, what I need to do is:

            1) make ClassAdapterFactory configurable
            2) Implement ClassAdapter. I will reuse the ReflectionClassAdapter since I currently think reflection is sufficient.
            3) hook in ClassAdaptor.getDependencies()
            4) Refactor AOP weaving/binding to be able to use MC registry to find AspectFactories and as a side effect abort weaving/binding if the factory isn't ready.

            I'll do this all programmitcally. I cannot write an AspectDeployer until the XML parsing is done. I'll need an XML parser that can handle XML fragments since AspectFactory implementations are pluggable (and must remain pluggable for things like SecurityAspect).

            So, second iteration will be:

            1) Write AspectDeployer

            3rd iteration will be:

            1) Morph GenericBeanFactory so that I can add additional injections like Advisor, InstanceAdvisor, TargetObject, etc.. Things only AOP can resolve.

            4th iteration:

            1) Rewrite DynamicAOP to be able to handle more fine-grain aspects.
            2) Refactor annotation overrides and maybe move it into the kernel or a separately shared module.
            3) Hook in per-instance annotation overrides with DynamicAOP (the getInstanceAdapter implementation

            I think maybe you need to handle the @Dependency stuff as it seems this may be something specific to MC and not soley an AOP thing. Is that correct?

            • 18. Re: using the registry/ClassAdapter.getDependencies()
              bill.burke

              Oh, most definately. I was assumingn that TM would be injected. In the case of security where the aspect needs to get what domain from the bean class, the domain would be looked up through the KernelRegistry.

              • 19. Re: using the registry/ClassAdapter.getDependencies()

                 

                "bill.burke@jboss.com" wrote:

                I think maybe you need to handle the @Dependency stuff as it seems this may be something specific to MC and not soley an AOP thing. Is that correct?


                Ok. We originally had this in the ClassAdapter because the jboss-aop.xml
                can add extra annotations/introductions. If you are saying this does
                not require any special processing in AOP land I am OK with doing this in the MC.

                • 20. Re: using the registry/ClassAdapter.getDependencies()

                   

                  "bill.burke@jboss.com" wrote:

                  1) Morph GenericBeanFactory so that I can add additional injections like Advisor, InstanceAdvisor, TargetObject, etc.. Things only AOP can resolve.


                  Isn't that the purpose of wrapping the generic bean factory in the aspect factory?
                  The GBF constructs and configures the advice object then the aspect factory
                  tells it the interesting stuff.

                  • 21. Re: using the registry/ClassAdapter.getDependencies()
                    bill.burke

                    Ok, shit, now I remember why AOP needed to create ClassInfos. Because of annotation overrides at the class level by the AOP container.

                    Yeah, I think MC should handle @Dependency, but ClassAdaptor will provide the ClassInfos (with overrides). Really I think the annotation override facility in JBoss AOP should be extracted into its own module so that MC can reuse it. It would be silly to map between ObjectModels that are doing the same thing.

                    Anyways. let's iterate. I need to iterate because I can't focus on this stuff continuously because of other responsibilities (i.e. EJB3).

                    • 22. Re: using the registry/ClassAdapter.getDependencies()
                      bill.burke

                       

                      "adrian@jboss.org" wrote:
                      "bill.burke@jboss.com" wrote:

                      1) Morph GenericBeanFactory so that I can add additional injections like Advisor, InstanceAdvisor, TargetObject, etc.. Things only AOP can resolve.


                      Isn't that the purpose of wrapping the generic bean factory in the aspect factory?
                      The GBF constructs and configures the advice object then the aspect factory
                      tells it the interesting stuff.


                      Yeah, this is what I'm talking about.

                      1 2 Previous Next