That is what I mentioned before when I asked about what you had done
with Scott's prototype since it didn't understanding joinpoints.

The answer was nothing, so when you try to store joinpoint metadata
it doesn't work.

I'm not sure that we want to allow any proprietary key.
I would expect joinpoints to be known to the system, e.g.

attrs.put(CommonNames.JOINPOINT, "something");

We are still struggling with the repository namespace. Let's get this agreed on here.

The scope portion of the key is fixed in terms of the allowed keys. All that a component can specify is the value of the scopes. The scope is a property of the component that loaded the metadata. It defines how broadly the data is applied. That is the definition of a scope. The repository should probably enforce that any addition with an unknown scope fails.

The name portion of the key is an arbitrary string namespace. We need to have a stable/well know basis for the data shared by aspects. This gets back to the other discussion of what the default convention was going to be. The suggestion was that this should be a package namespace style convention that correlates annotation class names with the same metadata coming from xml or other sources. This is the only name a consumer of repository data cares about in general. Something other aspect that understands how broadly the current context wants to look for metadata should be setting the scope that the context repository.getMetaData("name") applies to name. I guess this should be made manifest in the api somehow?

A joinpoint does not define a scope. I can have joinpoint metadata loaded from many scopes. A joinpoint is a type of metadata that should have a root in the string namespace, MetaDataNames.JOINPOINT="org.jboss.joinpoint" or some such.

Back to Kabir's question, how does proprietaryKey relate to permissions or scope? As far as I can see from the description, it is a qualification to "permissions", so "permissions.proprietaryKey" is what one would use to lookup the metadata.

Maybe the name portion needs to be an ordered sequence of srings (List[String]) to facilitate use of the name portion of the key.

If a joinpoint doesn't define a scope then how do you say for a service:
"Change the transaction timeout for that method on that instance"
or for an EJB
"Change the transaction timeout for that EJB method"

The class/joinpoint is where most people will add their annotations.
The information coming from other scopes will just be defaults
to avoid having to specify it in every context.

e.g. In the example above it would be the default transaction timeout.

So let's break this down into the scopes and name elements. The questions are:
1. What defines the visibility of the data (scope)
2. What defines the identity of the data (name)

In "Change the transaction timeout for that method on that instance" I see:

scope: (DEPLOYMENT="instanceID")
name: ("transactionTimeout", "methodName")

A transactionTimeout for the instance looses the methodName. A transactionTimeout for the deployment has key (DEPLOYMENT="deploymentID";name=("transactionTimeout")). A transactionTimeout for the server has key (SERVER="thisServer";name=("transactionTimeout"))

There is a lot of complexity hidden in the name portion of the key that I don't know has adequately been broken out. Consider a method name ala ejb where the signature portion (including interface) is an implied wildcard. Take that a step further and allow for regex patterns both in terms of the repository key, and the lookup name and it gets quite complicated to resolve the match(es) based on the Key alone. For these type of lookups there needs to be a query/iterator mechanism.

I don't understand the difference between visibility and identity.
Are you saying the consumer should loop over all the visible data
to determine what applies?

I didn't want to bring up cross-cutting definitions in the metadata
repository yet. :-)
I just want to get the basic class/joinpoint stuff working.

The fact that in future we might want some form of AOP style
cross cutting definition says to me that the consumer shouldn't be
involved in identifying what data applies.
This logic should be hidden inside the metadata query for
"give me the transaction timeout annotation for this method".

The key point of visibility is that its an aspect in my view. When I do a lookup on "transactionTimeout", the scope aspect is controlling whether this picks up request level overrides, a specific session binding, what deployment I am part of, and what admin domain applies. Its generally not something that the consumer of the metadata cares about, or has sufficient knowlege of.

Identity is best illustrated by the annotation to xml mapping you used. I need to match up the class level metadata to the xml metadata using a common identifier. Speaking of this example, there is no CLASS_LOADER scope currently. Really this is the visibility relationship between an annotation and deployment level overrides like descriptors.

Put another way, identity is something I can agree on independent of how many levels may provide a binding for the identity. You need to write a paper on determining the orthonormal basis for the repository Key space.

I hereby patent a process for the the orthonormal representation of crosscutting metadata in a dynamic environment. ;-)

I think what you are saying is that the only difference between
the scope and name is that the scope is implicit to the api
whereas the name (e.g. the method) is something the consumer has
to pass in.

In fact, from the AOP perspective the method is implicit as well.

I'll be happy as long as we are not leaking implementation details
into other layers. e.g. we can add things like the expression based
metadata in future:

scope: (DEPLOYMENT="instanceID")
name: ("transactionTimeout", "get*")

... without changing the code that asks for the metadata.

"adrian@jboss.org" wrote:
... without changing the code that asks for the metadata.

So we still haven't defined what the names mean.

I'm assuming from Scott said the Microcontainer names map to:

Application == KernelDeployment
Deployment == BeanMetaData/KernelControllerContext

This is a bit confusing.