[adrian.brock]

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.

I just had a quick look at your CVS commits, it looks good,
but I think you already know it limitations from your comments below?
You don't seem to have done anything with Scott's prototype?

We should probably make the exisiting Invocation.resolveAnnotation()

I'm not sure I understand this?

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.

Ok. My BeanMetadata doesn't really have a mechanism for overriding
method annotations yet anyway. It does for properties/fields and constructors.

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.

I'm currently working on this, so you can leave this to me.

[kabirkhan]

I just had a quick look at your CVS commits, it looks good,
but I think you already know it limitations from your comments below?
You don't seem to have done anything with Scott's prototype?

I didn't change anything in Scott's prototype, what do you have in mind? I'm just using it as is, wrapped in a MetaDataContext per bean. The key attributes determining the repository level are currently randomly hardcoded, but include the bean name.

We should probably make the exisiting Invocation.resolveAnnotation()

I'm not sure I understand this?

This refers to what I am mentioning below. There already is a resolveAnnotation() method on the various invocation classes. They check with the advisor's annotation repository (the one that already exists), and then hit the class. So we should be able to plug in the main repository there:

Object resolveAnnotation(Class ann){
 Object annotation = metadataCtx.getAnnotation(ann);
 if (annotation != null) return annotation;

 return advisor.resolveAnnotation(annotation); //checks the advisor's repository and the class
}

In reality I will probably this in the advisor.

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.

Ok. My BeanMetadata doesn't really have a mechanism for overriding
method annotations yet anyway. It does for properties/fields and constructors.

I'll take a look

[adrian.brock]

I just had a quick look at your CVS commits, it looks good,
but I think you already know it limitations from your comments below?
You don't seem to have done anything with Scott's prototype?

I didn't change anything in Scott's prototype, what do you have in mind? I'm just using it as is, wrapped in a MetaDataContext per bean. The key attributes determining the repository level are currently randomly hardcoded, but include the bean name.

Ok. Scott didn't have any notion of component/instance or joinpoint.
I see you've just made every bean an application which is obviously wrong ;-)

[adrian.brock]

We should probably make the exisiting Invocation.resolveAnnotation()

I'm not sure I understand this?

This refers to what I am mentioning below. There already is a resolveAnnotation() method on the various invocation classes. They check with the advisor's annotation repository (the one that already exists), and then hit the class. So we should be able to plug in the main repository there:

Ok, but again this doesn't seem to deal with joinpoints?
Can you override joinpoint annotations in AOP?

[adrian.brock]

Ok, but again this doesn't seem to deal with joinpoints?
Can you override joinpoint annotations in AOP?

Never mind, I found them.

[starksm64]

I didn't change anything in Scott's prototype, what do you have in mind? I'm just using it as is, wrapped in a MetaDataContext per bean. The key attributes determining the repository level are currently randomly hardcoded, but include the bean name.

Ok. Scott didn't have any notion of component/instance or joinpoint.
I see you've just made every bean an application which is obviously wrong ;-)

One thing we need to get straight and agree on are the scopes and their usage. What would be a component scope? I equate a component to the DEPLOYMENT_LEVEL.

[adrian.brock]

I mean component as in application component.
Like a User or Account type.

Somebody will want to maintain the repository and say
Accounts should be secured by domain "blah".

Another example of humpty dumpty :-)

[starksm64]

I mean component as in application component.
Like a User or Account type.

Somebody will want to maintain the repository and say
Accounts should be secured by domain "blah".

This gets back to the confusion Tom was having over the string/variable portion of the key namespace vs the scope in my view. Consider a security aspect that needs to enforce this access pattern. One piece of information needed is what key it uses to pull the domain from. In general I don't see aspects worrying about scope. The security aspect applied to Account instances has a notion of the domain it should use being under the key "security-domain" for example, and the scope that has such a binding is a dynamic function of what deployment, server defaults, admin, etc. that have loaded data under this "security-domain" key.

I do understand Tom's confusion from the perspective of wanting a stable namespace that can be shared across components. Its natural to want to segment this namespace into logical segments as well such that there is a common naming convention for security aspect related metadata.

[adrian.brock]

The aspects/advices don't worry about scope.
They have a link to the scope to use in their advisor.

In the case of components, e.g. individual services or pojo instances
you will configure some things at the instance level. For EJBs
you configure it per EJB or class.

My version of the hierarchy is to make it typesafe by using annotations.
i.e. The metadata key is the annotation class
org.jboss.security.SecurityDomain

This links in nicely with defining the default metadata in the class
and allowing overrides via MC xml.

e.g.

@SecurityDomain("foo")
public class MyService {}

<bean class="MyService">
 <annotation name="org.jboss.security.SecurityDomain">bar</annotation>
...

The annotation from the bean xml just goes into the instance scope
of the metadata repository ready to be retrieved by the advice.

[kabirkhan]

I have committed some more on this. Previously the MetaDataContext was injected into the class advisor, which meant in the JMXDecoratedTestCase that Bean1's metadata would overwrite Bean's metadata.

It is now injected into the instance advisor so each bean instance gets its own metadatacontext as intended.

I am still not really getting the discussions about metadata scope/levels/combiners. I know what I have done in that regard works, but is wrong. Does anybody have some more concrete examples?

[adrian.brock]

Sorry, I meant to write you some tests but I haven't got around to it yet ;-(
I'll try to get some done by the end of tomorrow.

You could work on adding joinpoint annotation overrides. e.g.

<bean>
 <property name="blah">Foobar
 <annotation name="com.acme.Annotation">whatever</annotation>

These should appear in the invocation api and affect that instance/joinpoint's
advices if that is relevant.

[adrian.brock]

I've reworked the test to show the issue.

The introduction is now based the annotation
@org.jboss.aop.microcontainer.prototype.introductions.jmx.JMX
which means it is not getting introduced if you add the annotation
via the repository metadata.

[kabirkhan]

I am currently working on hooking up the repository metadata with the advisors so it can be used in the matchers, which should fix this :-)