5 Replies Latest reply on Jan 7, 2005 4:10 PM by adrian.brock

    JBoss AOP Integration

    bill.burke

      Here's a kick of of how we should integrate JBoss AOP with the new kernel.

      1) We need to decide on the Invocation/Joinpoint model. I like the one you have defined in your kernel. We can switch to that, with some modifications of course.

      Some questions on it though:

      - Annotations should be able to be added/overriden on a per-bean basis. Therefore we need a getAnnotation() method someplace in the SPI. At first thought, it seems like the JoinPoint is a good place? Is there a JoinPoint created per "container"?

      - Also, aspects/interceptors need to obtain Annotations on the class/interface of the particular Joinpoint. These annotations can also be overriden by the container in question. We need to decide where this method will be. Is there some type of ClassJoinpoint? I couldn't find one at first glance.

      - getAnnotation and getClassAnotation should be added to the InvocationContext so that annotations can be overriden on a per context basis. The gives the aspect a choice on whether to obtain a "static" annotation or a "dynamic" one. For instance, Security would not want a dynamically overridable annotation.

      2) The SPI (at least the Joinpoint/Invocation/InvocationContext stuff) should be moved to the AOP package when AOP is ready.

      3) Interceptors/Aspects should be defined outside a bean and bound in via a bind statement (like in JBoss AOP). Not defined directly within the bean. Usually, it is the aspect that decides its scope: whether it is created per vm, per class, per instance, per joinpoint, and not the other way around.

      Bill

        • 1. Re: JBoss AOP Integration

          1) I need to understand why the get[...]Annotation() is not the same
          getMetaData.
          IMHO we should have one method for retrieving configuration.
          Additionally, metadata from the invocation should be able to override static
          annotation configuration.

          Besides we should start a different thread on this important area?

          2) I want the invocation/join point model external to AOP so I don't have to
          include jboss-aop.jar in some deployment scenarios. i.e. microcontainer must not
          import org.jboss.aop. Instead org.jboss.aop is a possible implementation of this spi.

          Also, I see aop using some of the dependency injection features in some
          deployment scenarios which means you have a circular reference:
          microcontainer imports aop (for container)
          aop imports microcontainer (for dependency injection)

          3) We are discussing this on a separate thread. I don't think you have understood
          my argument there. Interceptors should be added to the microcontainer's container
          using dependency injection.

          i.e. The container is not available publicly until the interceptors are injected
          => The container waits for interceptors to satisfy dependencies
          => Iterceptors wait for required services to be deployed
          Or in summary deployed beans are not available until theire required services
          are deployed. The link is via the aspect/interceptor so each service
          doesn't have to explicity define all its dependencies.

          e.g. a bean automatically gets a dependency on the transaction manager
          when it declares transaction demarcation.

          The bean

          @transaction required
          public doSomething()
          {
          }
          


          The interceptor
          public class TransactionDemarcationInterceptor
          {
           @Inject
           public void setTransactionManager(TransactionManager tm)
           {
           ...
           }
          }
          


          • 2. Re: JBoss AOP Integration
            starksm64

            I agree on the Annotation == MetaData comment. Espcially when you add in annotation overrides, annotations are just a java langague specific form of metadata with java centric scopes.

            • 3. Re: JBoss AOP Integration
              bill.burke

               

              "adrian@jboss.org" wrote:
              1) I need to understand why the get[...]Annotation() is not the same
              getMetaData.
              IMHO we should have one method for retrieving configuration.
              Additionally, metadata from the invocation should be able to override static
              annotation configuration.


              I don't care about the interface, but you need to have a distinction from statically defined annotations/metadata from invocation/context overriden annotation/metadata. You don't want the client overriding the allowed roles of the method, do you?


              2) I want the invocation/join point model external to AOP so I don't have to
              include jboss-aop.jar in some deployment scenarios. i.e. microcontainer must not
              import org.jboss.aop. Instead org.jboss.aop is a possible implementation of this spi.


              And I don't want AOP to have to include the microcontainer jar since it is separate.



              3) We are discussing this on a separate thread. I don't think you have understood
              my argument there. Interceptors should be added to the microcontainer's container
              using dependency injection.


              My point was that Interceptors/Aspects should be bean definitions and referenced via dependencies.

              Another problem is that interceptor/Aspects will have dependencies that cannot be resolved until they are bound. If the interceptor is PER_INSTANCE, for example, the interceptor may be interested in having the target's InstanceAdvisor injected. If it is PER_CLASS, then it may be interested in the target's ClassAdvisor.


              i.e. The container is not available publicly until the interceptors are injected
              => The container waits for interceptors to satisfy dependencies
              => Iterceptors wait for required services to be deployed
              Or in summary deployed beans are not available until theire required services
              are deployed. The link is via the aspect/interceptor so each service
              doesn't have to explicity define all its dependencies.

              e.g. a bean automatically gets a dependency on the transaction manager
              when it declares transaction demarcation.

              The bean
              @transaction required
              public doSomething()
              {
              }
              


              The interceptor
              public class TransactionDemarcationInterceptor
              {
               @Inject
               public void setTransactionManager(TransactionManager tm)
               {
               ...
               }
              }
              


              I think you made need the concept of a DynamicBean in wich the Bean's attributes do not result in a call to a setter, but rather a generic setter. Is there something like this?

              Please take a look at:

              http://docs.jboss.org/aop/aspect-framework/reference/en/html/xml.html#xml-aspect2
              http://docs.jboss.org/aop/aspect-framework/reference/en/html/xml.html#xml-aspect3




              • 4. Re: JBoss AOP Integration
                starksm64

                 


                I don't care about the interface, but you need to have a distinction from statically defined annotations/metadata from invocation/context overriden annotation/metadata. You don't want the client overriding the allowed roles of the method, do you?

                The scope at which metadata can be introduced is a property of the metadata. Its not the static nature of the security roles that defines where it can be assigned, its the scope. A client invocation should not be able to override the allowed roles at runtime, but an admin certainly should be able to.


                And I don't want AOP to have to include the microcontainer jar since it is separate.

                Something needs to be the base library here. Its pointless to have the same functionality in different packages.


                My point was that Interceptors/Aspects should be bean definitions and referenced via dependencies.

                Its not clear why this must always be the case. If there is a pure contains relationship to any injection, be it an attribute or interceptor why can't it be defined in a embedded manner?


                Another problem is that interceptor/Aspects will have dependencies that cannot be resolved until they are bound. If the interceptor is PER_INSTANCE, for example, the interceptor may be interested in having the target's InstanceAdvisor injected. If it is PER_CLASS, then it may be interested in the target's ClassAdvisor.

                This is a clear case of not being a pure contains relationship. A security interceptor may depend on a specific security domain being started.

                The clear rationale for bean definitions and injection via reference is to allow for canonical configuration files. The syntax argument for this would be simply that the associated schema is more likely able to be validated.


                • 5. Re: JBoss AOP Integration

                   


                  I think you made need the concept of a DynamicBean in wich the Bean's attributes do not result in a call to a setter, but rather a generic setter. Is there something like this?

                  Please take a look at:

                  http://docs.jboss.org/aop/aspect-framework/reference/en/html/xml.html#xml-aspect2
                  http://docs.jboss.org/aop/aspect-framework/reference/en/html/xml.html#xml-aspect3


                  Per instance and per joinpoint is also something JBossMX has.
                  i.e. you create an interceptor for each attribute or operation.
                  I didn't implement that in my prototype because I wanted to keep it simple.
                  This is just a different configuration. The pseudo configs I have shown above
                  don't include this since I wanted to keep it simple.

                  My plan was to have Kernel/Container/JoinPoint awareness.
                  This is a generalization of MBeanRegistration/ContainerPlugin
                  that can be implemented by the target, but I anticipate it will be more often
                  implemented by the aspects and subservices
                  to define their scope and do some optimization at deployment time.

                  Related is the notion of service/subservice where the microcontainer
                  handles deployments like the JMXInvoker/interceptors,
                  EntityContainer/LockManager, EJBContainer/ProxyFactory,
                  JDBCStoreManager/FieldBridge, etc
                  rather than each service having to provide its own solution.