Boston meeting notes: AOP container integration
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