It will when I've integrated it (probably this weekend?)

This is my task, you've already provided "the path"
on where the metadata needs to be, I'm just changing the implementation.

It is the org.jboss.metadata in the container project.

The three major parts that need doing are:
1) Creating the composite metadata tree from the key scopes
2) Mechansims to deploy metadata at different scopes
3) Adding constructor, method, parameter annotations to the api.

I've outlined (1) elsewhere, but it is not trivial because of the
"feedback" used to construct the tree, e.g. the deployment determines
the cluster.

(2) is really an issue for the deployers

(3) needs to define a "joinpoint notion" so you can for instance
say I want to override the annotations/metadata for this method/constructor
I didn't look at how you did this with the org.jboss.repository stuff

I stopped doing this before to work on the deployers but now I've
got to the stage where I'm going to get back to it with the deployment
metadata population/overriding.

Ok, I'll take a look at what you did when I have time.

You probably did it wrong, but that's ok. ;-)

Like I said on a different thread (in the POJO forum), the real solution is to
provide two different views of the metadata.

1) The particular level that is modifiable, e.g. the AOP instance annotations
e.g. (scope key) instance=SomeInstanceId
2) The tree structure that is used at runtime and is read only
instance=SomeInstanceId,class=com.acme.Blah,deployment=whatever.jar,etc.
this is made up on the particular levels defined in (1)

The repository needs to contain both views.

I've committed the code for this refactoring

AOP-CHANGES

It required a change to the AOP advisor to map MetaDataContext -> MetaData
I left the old class still in the repository in case somebody does a partial
integration (don't want NoClassDefFoundError).

I hope I didn't break anything, the aop-mc-int tests weren't in a good shape
(e.g. all the weave tests were broken).

KNOWN TEST ISSUE (Metadata stack)

We'll actually I know I broke one thing, but that would be easily fixed if
we decide it isn't a useful feature.
Basically when I callout to a joinpoint I push the metadata onto the
org.jboss.metadata.spi.MetaDataStack
this is how I pass the MetaData to aop,
but it also means the constructor or lifecycle methods can peek
the metadata.

However, this seems to confuse AOP since the lazily loaded aspects
also seem to pick up this metadata.
For now I'm "masking" this stack in the AOPConstructorJoinpoint
but that means some of the new tests are failing because the constructor
expects to be able to peek the stack.

Maybe this isn't such a good idea and it should be a feature provided
optionally by an interceptor at runtime?

ANNOTATION SUPPORT

The new MetaData has support for all types of annotations
(field, constructor, method, method parameters - in fact whatever
you can think of as a "Signature"), but the MC xml still doesn't support
overrriding all these.

DEFINING SCOPES

The major piece of work that is left is to replace the
BasicKernelMetaDataRepository.initMetaData()
with something that knows how to properly construct scoped metadata contexts.
This is going to require some kind of "plugin' mechanism away from the
MC since this is likely to get very JBossAS specific, e.g.
clustering or transaction local scopes.

The only scopes currently supported are hardwired:
instance, class and JVM

REPOSITORY.JBOSS.COM

Finally, I put this in the repository as "snapshot-metadata" because
I don't want the JBossAS build picking this up until Kabir has had a chance
to verify it.

"kabir.khan@jboss.com" wrote:

Is this snapshot taken from trunk? I need to create one for JDK 1.4 as well to get the aop tests passing

I'm not sure I understand the second part, but I understand the first part.

The answer to the final question is that the cutoff for creating an instance proxy
is whether it has instance annotations (or metadata - objects).
Obviouslly if there are server annotations (like default transaction timeout)
they will be shared by all instances.

The object you are getting is the MetaData (read only and merged)
which is the object that you should use in AOP.

However, this does not tell you if there are instance annotations.
What you really need to do is the following (pseudo code):

// Get the instance retrieval for this context
KernelMetaDataRepository repository = kernel.getMetaDataRepository();
MetaDataRetrieval retrieval = repository.getMetaDataRetrieval(context);

if (retrieval.isEmpty() == false)
 // Need an instance proxy

On the final point (InstanceClassInfo), although this would make the BeanInfo
opaque, you could just ask the InstanceClassInfo if it has instance annotations,
it is not a good solution anymore because the MetaData has been expanded
to include abritary objects (not just annotations) which don't fit well
with the ClassInfo notion.