AOP/MC Next Step

[adrian.brock]

The proxy is looking really good now. A lot better than my DP prototype :-)
I've still got to look at Mixins and other ways to break it. :-)

Can this be moved to AOP rather than Aspects?
It will probably mean rewriting some of the tests to not depend upon jboss-j2ee classes?

The next step is the typed metadata integration:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73653

[kabirkhan]

I;ve had a look at the metadata stuff. Can you please explain what the "MetaDataContext" is as outlined in the other thread?

[adrian.brock]

It is the object that tells you what you are searching for and where to start searching.

I think in Scott's prototype it is called "Key"

public interface KernelRepository
{
 public Object getMetaData(Key key);
...

I'd prefer it if this more implicit, i.e. the context holds a link to the repository
and the thing you were searching for is just the annotation class name
with an interface like AnnotatedElement from the JDK.

That way the Advisor/joinpoint just needs a mechanism to hold the context
initialized either
* implicity based on deployment config
* a setter method on the advisor
* a parameter on the proxy factory methods

e.g.

class Advisor
{
 setMetaDataContext(MetaDataContext ctx);
}

// Interceptor usage
public Object invoke(Invocation inv)
{
 MyAnnotation x = inv.getAnnotation(MyAnnotation.class);
}

Effectively Maps to
MetaDataContext ctx = inv.getAdvisor().getMetaDataContext();
MyAnnotation x = ctx.getAnnotation(MyAnnotation.class);

With the later in Scott's prototype mapping to:
KernelRepository rep = ctx.getRepository();
Map scope = ctx.getScope();
Key key = new Key(MyAnnotation.class, scope);
return rep.getMetaData(key);

[adrian.brock]

The thing I don't see in Scott's prototype is the ability to retrieve/manage
the joinpoint metadata, e.g. changing method transaction timeouts via the repository.

This also needs be done as a part of the invocation.getAnnotation(...)

[adrian.brock]

In case the requirement is not clear, the idea is that
code will go to the metadata repository to retrieve annotations
rather than asking the classes directly.

The most important consumer being the advices.

This metadata repository can be populated at different levels,
e.g. deployment, server, cluster

The simplest possible metadata repository implementation
(e.g. for simple standalone usage) is to just proxy requests to the reflection api.

[kabirkhan]

I'm still not totally with you. I get the basic idea of what happens when the invocation needs to use the repository. I'm missing the bit of who owns the repository.

Will there eventually be one repository installed in the Microcontainer at startup? If so will this (i.e. which MetaDataCombiners exist) be managed by the KernelConfig?

Or do you see it as being created as a bean, and somehow injected into the advisors of the advised classes?

Or am I missing the point and the repository is actually set up somewhere else?

Once I have a reference to the repository it should be possible to pass this in to the created advisor via the proxy factory.

[starksm64]

The repository will be configured as a bean, and there will likely be repository aspects that associate MetaDataCombiner/MetaDataLoader as well as the default starting scope starting point/Key.

The default MetaDataCombiners/MetaDataLoaders would also be configured at the mc bean level to define the namespace used for metadata from the kernel.

This is how I see the repository used.

[adrian.brock]

That is correct. The AOP layer doesn't really need to worry about how it
gets the repository reference, only the mechanism to use it once it is injected.

Once we have the basic mechanism in place, we will likely want to look
at how this relates to things like AOP domains in terms of contextual configuration.

[adrian.brock]

The basic flow (I'll write a test next week)
is that the MC will instantiate the repository and load it with application context data
(beyond what is already defined in the class annotations).

The advisor will then be injected with the MetaDataContext (a link into the relevant
part of the repository) which can be used by the advices to retrieve this metadata.

[kabirkhan]

I've got the bulk of this fleshed out, and I am reworking your JMXDecoratedTestCase to use this.

I've got an AOP version of KernelRegistry set up to do some special handling if the data we are setting is an instance of AnnotationMetaData. If it is I use Bill's annotation proxy to implement the interface.

The problems I am having (mainly cause I'm afraid to change the API) are:

I am setting up DescribeAction to define the metadata in the repository as defined here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76685
The repository is installed as a bean via the config xml, but when using the repository from DescribeAction I am currently hardcoding the name of the repository to be used.

I've got AOPConstructorJoinpoint set up to create the MetadataContext and inject into the advisor. However, there is no way to get the name of the bean that should be installed, something which would be useful for construction of the key. Again, since I have no access to the kernel from AOPConstructorJoinpoint I have a pretty nasty hack in place to get hold of the repository (basically the AOPKernelRegistry is a singleton with a static factory method). I would like for the KernelControllerContext to be propagated to the joinpoints if possible. Not sure if that fits in with your plans?

[adrian.brock]

I've been looking through this today.

Basically I want to move the AOPClassPool stuff to container and use it
for the javassist ClassInfo.

The AOPClassPool doesn't look to have any dependency on AOP
other than the link to the aspect manager which holds the classloaders
such that it can be told when classloaders are undeployed.

It will be trivial to move this into a new data structure in container
and make the AspectManager talk with the new datastructure.

Then we need to link it to the metadata repository such that the MC
can add instance annotations.

I had a quick look at Bill's annotation stuff which looks like a clone of
something already in javassist? Except it has links into the xml deployment layer.

We need this annotation stuff in the ClassInfo/metadata layer anyway for
the retro style processing and annotations set in xml policy config or metadata loaders.

[adrian.brock]

I've got the bulk of this fleshed out, and I am reworking your JMXDecoratedTestCase to use this.

Good

I've got an AOP version of KernelRegistry set up to do some special handling if the data we are setting is an instance of AnnotationMetaData. If it is I use Bill's annotation proxy to implement the interface.

The problems I am having (mainly cause I'm afraid to change the API) are:

I am setting up DescribeAction to define the metadata in the repository as defined here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76685
The repository is installed as a bean via the config xml, but when using the repository from DescribeAction I am currently hardcoding the name of the repository to be used.

I've got AOPConstructorJoinpoint set up to create the MetadataContext and inject into the advisor. However, there is no way to get the name of the bean that should be installed, something which would be useful for construction of the key. Again, since I have no access to the kernel from AOPConstructorJoinpoint I have a pretty nasty hack in place to get hold of the repository (basically the AOPKernelRegistry is a singleton with a static factory method). I would like for the KernelControllerContext to be propagated to the joinpoints if possible. Not sure if that fits in with your plans?

Ignoring the horrible API which I've still got to fix, I'm actually thinking of not
overriding the annotations via the ClassInfo/ClassAdapter and instead
the MC would just install the annotations as instance level metadata in the
metadata repository.
This should work provided AOP is looking at instance level annotations when
it is applying the pointcuts.

So the MC/AOP annotation integration would basically boil down
to something like the MC injecting the metadata context into the ClassAdapter
instance ready for AOP to pick and use when it creates the instance.

I'm not sure how easy this is for you at the AOP level?
e.g. can you easily understand that when instance level annotations exist
you might need to create a proxy if the annotation creates an introduction?

[adrian.brock]

(basically the AOPKernelRegistry is a singleton with a static factory method).

You shouldn't need to do anything with the MC registry or the metadata registry.
You should be using the metadata context (which you get passed) and the classinfo
since you are only interested in the annotations and the joinpoints.

[adrian.brock]

Finally, I want to make sure we have minimal disruption to AOP.
i.e. If somebody is using AOP without the MC/metadata repository.

So we need to make sure the moving of the AOPClassPool to container
and other changes doesn't pull in lots of dependencies.

I'm wondering how we can abstract the MetaData context, etc. such that you
could just use a simple version that maps directly onto the old class/ctclass stuff
in the joinpoint parsing, rather than introducing a third mechanism.

e.g. the joinpoint parsing already has Method and CtMethod variations.
It would make more sense to me to have a single api that could be these
or it could be the metadata repository for annotations.

A bit like what I have done with ClassInfo where it can come from plain reflection
or it can come from javassist.

[kabirkhan]

I've worked around the problems I mentioned by moving construction of the MetaDataContext further into the kernel, and initialising it in KernelControllerContextActions. AFAICT the main thing I have done to any API which isn't considered stable, is adding KernelControllerContext.get/setMetaDataContext() methods. There may well be a better home for this, so please take a look.

We should probably make the exisiting Invocation.resolveAnnotation() methods check with the repository first before doing what it is already doing now? Or maybe I should move this into the Advisor, so that the matchers use the same interface as now when determining if something should be advised. The repository (my stuff anyway) currently only handles class-level annotations, we need a way to apply this to methods/constructors/fields.

There is no way to know if an annotation will introduce introductions yet, so I need to think a bit about that one.

Where (package name) in the container project do you want the ClassPool stuff? I can start looking at moving that over. It would be nice to get the matchers working using ClassInfo to avoid all the duplicate code as well.