JBMICROCONT-18

[kabirkhan]

I've started taking a look at the microcontainer, as I have been assigned this JIRA task. While what's been done for org.jboss.aop.microcontainer.prototype.* makes sense, it is not clear to me what I should be doing for this task.

Is what we are after something similar to the existing annotation overrides? If not can we flesh out what is needed here a bit so I can get started?

[adrian.brock]

There are a number of issues. This is just the one that is in the MC project.
The others are against aop in JIRA.

Let me re-iterate the proxies work then I'll come back to annotations.

[adrian.brock]

So proxies/advised pojos.

The requirement here is to be able to advise a POJO at instance level
(to override annotations/metadata - see later) for this instance.

My main requirement is to advise the POJO using a sort of Introduction
that acts upon the Microcontainer lifecycle to do extra work for the POJO
during deployment. I call these "Decorations" in another thread.

See the JMXIntroduction test in the aspects project for a more complete test.

My prototype isn't very good because it requires you to wrap the POJO
for all methods, i.e. runtime exceptions even though these might not be advised.
It also doesn't support "hollow instances" - see below about "On Demand".

There are a number of possible circumanstances to support:
1) Unadvised -> Just use the object
2) Already AOP advised with no instance metata -> use the aop advisor
3) Already AOP advised with instance metadata -> need an instance advisor
4) Not AOP advised - need to add an advisor (either class or instance)
4a) Just Microcontainer lifecycle advices - only this part is advised
4b) Other runtime advices - the whole object is advised

I differentiate Microcontainer advices and the normal advices because
the MC needs the ability to advise the abstract notion of the instance,
i.e. before the object is instantiated.

More concretely, lets take the case where the user wants to trigger JMX for the MC
with "On Demand". The idea being we create and register an MBean for the
instance that does not exist, then when somebody clicks "start" it actually
creates the real object.

<bean name="Foo" mode="On Demand">
 <annotation name="JMX"/>
</bean>

This will add the KernelControllerContextAware Introduction
which the JMX advice processes by (un)registering an MBean wrapper.

When the user clicks start, the MBean calls back onto the KernelControllerContext
to actually install the object.
Obviously, this advice shouldn't apply on the normal methods the POJO.

Feel free to ask questions, I haven't gone into the advised/nonadvised proxy
debate. Bill and I have gone over this endlessly with the argument always
boiling down to:

Bill: I think AOP can do what you want all environments
Adrian: Prove it, e.g. make it work in an applet (acid test)
Bill: We need to do this in steps, I can't do everything straight away
Adrian: OK
Bill: But I'm working on EJB3 anyway :-)

[adrian.brock]

For annotations the idea is come up with a common model.

The sources of annotations will be
* The class
* aop deployment info
* microcontainer config
* The metadata service that Scott is prototyping

This should all got merged into a single view, that provides type safe metadata.
Most commonly this will be used from the SimpleMetaData in Invocation
but not exclusively, e.g. management apps will want to look at/configure this
externally.

If you look at JMXIntroduction, it is just using the MC metadata directly.

There is a sort of shell for this in the ClassInfo abstraction in the container module.

I think this also links into "retroweaving" where we want to backport code
written with JDK5 onto JDK1.4

If somebody does

MyClass.class.getAnnotation(MyAnnotation.class)

this would be weaved to something like

MetaDataRepository.getAnnotation(MyClass.class, MyAnnotation.class)

Additionally, we need to examine annotations that introduce dependencies,
such that these can be added to the MC context for correct deployment.

e.g.

@SecurityDomain("MyRealm");
public class MyClass {}

Would have meta annotations on SecurityDomain that says
MyRealm is a dependency. i.e. This class needs the security domain
in an installed state before it is installed.

The overall protocol is roughly outlined in the describe/instantiate part of the MC's
KernelControllerContextActions.
It uses the ClassAdapter as a kind of notion of class/instance that doesn't
yet exist.

The ClassAdapter is actually hidden behind the BeanInfo objects.
This is because the BeanInfo can change if the extra annotations
add new interfaces/methods.

Pseudo code:

Describe:
BeanInfo info = BeanInfoFactory.getBeanInfo();
addMicrocontainerAnnotations(info); // This does not exist - JBMICROCONT-18
ControllerContext.addDependencies(info.getDependencies()); // info.getDependencies() doesn't do anything either currently.

Instantiate:
Joinpoint jp = getConstructorJoinpoint(beanInfo, ....);
jp.dispatch();

The *gotcha* is that getConstructorJoinpoint could return a method
invocation, if it is on a factory, e.g. a singleton.
It is the factory's responsibility to control/configure the object, we can't really
add annotations to an object that somebody else constructs (except through
normal AOP config).

[adrian.brock]

Like it says in the Microcontainer documentation.
http://docs.jboss.org/nightly/microkernel/docs/reference/en/html/

The current api:
* Reflection Model: ClassInfo
* Integration: ClassAdapter
* Joinpoint
* JavaBean model - BeanInfo

Is considered unstable.

It can morph (or change enitrely) if we think there
is a better way to integrate the Microcontainer and AOP.

I'm not very happy with the way Bill's or my prototype determine the
AspectManager/Domain to use.
This would be better expressed through the metadata context of the
application/deployment.

i.e. This application/subsystem uses this Domain for its AOP config.

e.g. separate domains for JBoss Messaging, EJB3, JCA advices.

Bill sort of has some of this idea in EJB3, but I can't say I have looked
too deeply at it.

[adrian.brock]

The first things we need to get this working is the Microcontainer
being able to use the real AOP instance proxy advisors
and we need to share the annotation model.
i.e. drop my prototype

Some of the edge cases and things like linking to Scott's metadata repository
or dependencies from the annotations can come later.

Even using a single AOP domain (the AspectManager.getInstance())
is ok to start with.

We just need to keep the future requirements in mind when designing the
api we will use to communicate with each other.

And correctly separate our concerns. e.g. I shouldn't need to know
in the Microcontainer much about how the invocation or metadata context works.
The Microcontainer will only be involved in this when it populates it,
i.e. it is just like configuring any other service.

[adrian.brock]

i.e. drop my prototype

Also my prototype sucks big time.
After a couple of other optimizations in AOP, a stress test for creating and using
an instance proxy shows it spending something like 90+% of its initializing the
ClassContainer.

Most of this time is spent matching method pointcuts.