KernelControllerContextAware

[adrian.brock]

"
[JBAOP-210] Do some better management of when things are added to the advisors map of the AspectManager/Domains

When run by the MC we force the proxy containers to implement KernelControllerContextAware, and we unregister the instance advisor from the domain in the unsetKernelControllerContext(0 method.
"

This isn't a good solution to the problem.

KernelControllerContextAware is a prototypical interface so
we can test the AOP integration. I am going to replace it with
a fuller lifecycle that a "Decorator" can intercept.

Besides that, it isn't necessarily going to be a proxy.
That's something I am going to add tests for once the
Real AOP/MC smoke test is working.

[kabirkhan]

"
That's something I am going to add tests for once the
Real AOP/MC smoke test is working.

Is it not working for you?

[adrian.brock]

It wasn't. I didn't realise you had fixed it?

[kabirkhan]

"

Besides that, it isn't necessarily going to be a proxy.

True, an oversight on my part.

"
This isn't a good solution to the problem.

In that case I need some alternative way to hook in to when a bean is unregistered, so I can take necessary action. If the decorators can be configured similarly to the AOPJoinpoint stuff somehow, it can go in there instead.

The root of the problem is the need for the LazyGenericBeanAspectFactory, so maybe we need to rethink how that works? I'll look a bit more into what is actually going on.

[adrian.brock]

The problem is there is no real dependency.

The Aspect definition is deployed to AOP immediatley
but there is no mechanism to link the redeploy of the advice factory
to a reworking of what AOP has cached.

The rebind() is an ugly way to do this.

What we really need is for the advice factory installation into the
AspectManager to be under the control of MC such that it
gets reworked when it is redeployed. This also removes the
need to do the lazy lookup.

A related problem, that I am going to write a test for,
is that we need to differentiate "static" advice factories configured
through an -aop.xml and those done under the control of the MC.
The former should NOT be returned from getDependencies().

[adrian.brock]

The smoke test works now. Thanks.

[adrian.brock]

I've started those tests on the advisor implementation, I mentioned above.
To run them

ejort@ejort:~/jboss-head/aspects$ ./build.sh -f build-test50.xml test -Dtest=microcontainer/advisor/test

The idea is to test that decision table we discussed in Neuchatel
on what type of advisor needs to be implemented based on whether there are
instance level metadata overrides
and whether the object is already aop advised.

[kabirkhan]

I got rid of the KernelControllerContext hack.

Now, when the prototype Aspect wrapper starts, if it has been installed to "lazily" use a bean with a dependency, it will programatically install a "Listener" bean that starts when the dependency is started. This more or less achieves what the install elements did, but allows us to simplify the xml to:

<bean name="InterceptedAspect" class="org.jboss.aop.microcontainer.prototype.Aspect">
 <property name="adviceBean">InterceptedAdvice</property>
 <property name="manager"><inject bean="AspectManager"/></property>
 </bean>

I'm not with you with regard to

This also removes the need to do the lazy lookup

[adrian.brock]

I mean if we change the logic to a push then there is no need for
the lookup (pull).

There are three pieces:
pointcut definition
advice instance(s)
advice factory

Only the pointcut definition must be registered with AOP directly.
If the act of re-installing the advice factory pushed itself into AOP
then it could update the advice instance(s) at that point.

This is what the install does.

[kabirkhan]

I've continued down the path I was on. The "listener" bean now gets injected with the beanfactory we are depending on and injects this into the LazyGenericBeanFactory once ready (via the Aspect).

We currently have two ways of defining aspects.

If InterceptedAdvice has a dependency:

 <bean name="InterceptedAspect" class="org.jboss.aop.microcontainer.prototype.Aspect">
 <property name="adviceBean">InterceptedAdvice</property>
 <property name="manager"><inject bean="AspectManager"/></property>
 </bean>

If InterceptedAdvice has no dependency:

 <bean name="InterceptedAspect" class="org.jboss.aop.microcontainer.prototype.Aspect">
 <property name="advice"><inject bean="InterceptedAdvice"/></property>
 <property name="manager"><inject bean="AspectManager"/></property>
 </bean>

With the stuff in cvs now, the first way should be enough. The "listener" manages the dependencies

[adrian.brock]

But this is just more complication and moving even further away from IOC.
And it is completely unnecessary except for when it is a PER_VM advice.

All I want is to be able the inject advice factory into the aop config
when it is fully constructed. The order of what happens should be:

1) Add pointcut definition to AOP
2) Deploy bean that matches the pointcut (waits for advice factory)
3) AdviceFactory dependencies resolved -> update aop config with advice factory
4) Create beans that use the advice factory

For redeploy
1) Undeploy beans using advice factory
2) Remove advice factory from aop config
3) Undeploy dependency of advice factory
4) Redeploy dependency
5) Add new advice factory back into aop config
6) Redeploy beans using advice factory

The only reason this fails is because my prototype doesn't do
(2) and (5).

It did until we realised this meant that the pointcut definition
was undeployed as well. Which meant aop didn't know there
was a dependency because as far as it was concerned the pointcut
didn't apply.
To fix that we broke the connection and used the lazy lookup
rather than injection.

[adrian.brock]

The "listener" manages the dependencies

It is the JBoss of the Microcontainer to manage dependencies.

Building complicated processes to workaround other kludges just
means that other features won't be available. e.g. on-demand

[adrian.brock]

Now that I've done this feature:
http://jira.jboss.com/jira/browse/JBMICROCONT-73

We can do a proper version of the aop beans.

e.g. instead of

<deployment xmlns="urn:jboss:bean-deployer:2.0">

 <beanfactory name="InterceptedAdvice" class="org.jboss.test.microcontainer.support.InterceptorWithDependency">
 <property name="simpleBean"><inject bean="Dependency"/></property>
 <install bean="InterceptedAspect" method="rebind"/>
 <install bean="InterceptedBinding" method="rebind">
 <parameter><inject bean="InterceptedAspect" property="definition"/></parameter>
 </install>
 </beanfactory>

 <bean name="InterceptedAspect" class="org.jboss.aop.microcontainer.prototype.Aspect">
 <property name="adviceBean">InterceptedAdvice</property>
 <property name="manager"><inject bean="AspectManager"/></property>
 </bean>

 <bean name="InterceptedBinding" class="org.jboss.aop.microcontainer.prototype.AspectBinding">
 <property name="pointcut">execution(* @org.jboss.test.microcontainer.support.Test->*(..))</property>
 <property name="aspect"><inject bean="InterceptedAspect" property="definition"/></property>
 <property name="manager"><inject bean="AspectManager"/></property>
 </bean>

We can hide all the ugly xml and implementation details:

<deployment xmlns="urn:jboss:bean-deployer:2.0">

 <aop:advice xmlns:aop="urn:jboss:aop-deployer:1.0"
 name="InterceptedAdvice"
 class="org.jboss.test.microcontainer.support.InterceptorWithDependency"
 >
 <property name="simpleBean"><inject bean="Dependency"/></property>
 <pointcut>execution(* @org.jboss.test.microcontainer.support.Test->*(..))</pointcut>
 </aop:advice>

[kabirkhan]

OK,

So to be clear, you want something based on what we had before my workarounds? i.e. a variation of this:

<deployment xmlns="urn:jboss:bean-deployer:2.0">

 <beanfactory name="InterceptedAdvice" class="org.jboss.test.microcontainer.support.InterceptorWithDependency">
 <property name="simpleBean"><inject bean="Dependency"/></property>
 <install bean="InterceptedAspect" method="rebind"/>
 <install bean="InterceptedBinding" method="rebind">
 <parameter><inject bean="InterceptedAspect" property="definition"/></parameter>
 </install>
 </beanfactory>

 <bean name="InterceptedAspect" class="org.jboss.aop.microcontainer.prototype.Aspect">
 <property name="adviceBean">InterceptedAdvice</property>
 <property name="manager"><inject bean="AspectManager"/></property>
 </bean>

 <bean name="InterceptedBinding" class="org.jboss.aop.microcontainer.prototype.AspectBinding">
 <property name="pointcut">execution(* @org.jboss.test.microcontainer.support.Test->*(..))</property>
 <property name="aspect"><inject bean="InterceptedAspect" property="definition"/></property>
 <property name="manager"><inject bean="AspectManager"/></property>
 </bean>

If this is the case, I will get this working properly, without the hacks I put in and then look at using the nicer xml/BeanMetaDataFactory stuff.

[adrian.brock]

Yes please.

P.S. Feel free to change the prototype beans.
But I'd like to have them IOC based (as much as possible).

Although the user won't see them if they use the "use case xml"
the Microcontainer does see the three beans that make up the
aspect definition.

I was going to make a start on the aop xml today,
but obviously this is really something you should be happy with
and capable of maintianing.

I also want to add an

<aop:introduction>
 <interface>com.acme.Blah</interface>
 <pointcut>@com.acme.BlahAnnotation</pointcut>
</aop:introduction>

<bean>
 <annotation>com.acme.BlahAnnotation</annotation>
</bean>

so I can test adding introductions/interceptor/mixins via the bean metadata.