0 Replies Latest reply on Feb 6, 2005 10:27 AM by Adrian Brock

    Boston meeting notes: AOP container integration

    Adrian Brock Master

      The following are the assumptions and decisions taken about the aop container
      integration.

      Since container is an overloaded word, in this context it means the advisor
      in jboss-aop language.

      Assumptions/Decisions:

      Interceptor SPI - JBoss AOP model will be the only container integration
      By this we mean when writing advises/interceptors these will be targeted at
      JBoss AOP. There will no attempt to define an interface spi to expose this abstraction.
      i.e. Invocation, Interceptors, etc.
      These are an implementation details of JBoss AOP. The integration/abstraction belongs
      at the JoinPoint model (JoinPointFactory)

      ClassAdaptor - The integration will be done through something we have tentatively called a ClassAdaptor
      The ClassAdaptor is responsible for the following operations
      (see elsewhere for the details of these functions):
      * ClassData access to the class metamodel (inc before the class is not loaded)
      * Annotation processing - for retrieving and defining annotations and their overrides
      (inc before the class is not loaded)
      * Analysing the dependencies of a class, i.e. those introduced via annotations and
      the annotations on aop advices
      * Obtaining access to the JoinPointFactory (JPF) which provides access to the join point model

      There will be two ClassAdaptor implementations:
      * AOPClassAdaptor - too use an advised bean
      * BeanClassAdaptor - for unadvised beans that don't need a container (i.e. simple java bean)

      AOP and the MicroContainer - Push/Pull configurations
      AOP must still work standalone and in JBoss3 and JBoss4, even after the changes
      we are making
      This means AOP must effectively work in three modes
      * The current pull configuration where advisors pull their configuration from the AspectManager
      * A push model where the container "pushes" configuration to the advisor and advices
      * A mixture of the two above where some advices (those in the microcontainer) use push
      and others (applications deployed in JBoss) use pull
      This will be achieved by the MicroContainer using the ClassAdaptor to pre-analyse the
      advice configuration and dependencies declared on classes before the class is loaded.
      Only when the dependencies are satisfied will load the class and retrieve the Advisor (JoinPointFactory)
      The pull model may fail if dependencies are not satisfied. This is what you get if you
      don't use the MicroContainer/IOC

      Advisor types - The different advisor usage
      The type of AOP advisor will vary with the usage/configuration:
      * ClassAdvisor - as now for JBoss AOP where the bean instance requires no special
      annotation overrides at the instance level
      * InstanceAdvisor - where the MicroContainer wants to override annotations at the
      bean instance level
      * ProxyAdvisor - where the bean instance has not been instrumented for AOP - this will have the disadvantage that some join points like field interception will not work

      AspectFactory names - dual registry
      The aspect factory names are used in two places
      * The AspectManager to configure pointcut advices
      * The MicroContainer to determine whether the dependencies are satisfied
      They will have the same name in both configuration spaces

      Standalone MicroContainer
      The core micro container will know nothing about AOP, it will use the BeanClassAdaptor.
      An extension to the MC's controller will allow the AOPClassAdaptor to be used instead
      when the MC is deployed with AOP