Decorations
So I just added a prototype test of what I call "decorations".
More accurately they are just Bill's annotated point cut advices, except they act
upon a particular instance with the advices being stateless.
We are not there yet:
* Complete AOP/MC instance integration
* Integrate and implement MC annotations with aop annotation model
but I will be working with Bill to get this working properly.
Why is this important? Because it lets you set policy using simple metadata
that is within the context of the instance rather creating artifical addon beans.
e.g. IOC style
<bean name="Bean1" .../> <bean class="org.jboss.jndi.Binding"> <property name="Target"><inject name="Bean1"/></property> <property name="JndiName">whatever</property> </bean>
e.g. Decorations
<bean name="Bean1" ...> <annotation name="org.jboss.jndi.Binding"> <attribute name="JndiName">whatever</attribute> </annotation/> </bean> pointcut @org.jboss.jndi.BInding apply-advice org.jboss.jndi.JNDIBindingAdvice
There are other advantages to this approach. The major one being that
because the advice acts "in front of" the instance rather than as a dependency
of it, you don't need the instance to actually be in place or fully deployed.
This is important for providing things like jsr77 support where you want to redirect
lifecycle events:
jsr77mbean.stop() -> jsr77advice -> controllercontext.stop() -> controller -> dependencies.stop() -> instance.stop()
It also allows us to potentially put mbeans out there for management purposes
with on-demand beans that don't even exist or also implement redeploy
with valves properly.
Finally the extra indirection of the annotation also allows the policy of things
like jndi binding to be more easily overridden as a cross cutting concern
with a single stateless advice providing the policy or more likely a default
policy link in the annotation itself (for even greater flexibility).