[starksm64]

The first step is introduce the mechanism where each context
gets two scopes.
1) Their mutable metadata that they modify/populate
2) The metadata hierarchy they belong to.

Besides the mutable metadata contexts belonging to the deployers
there also needs to be a deployer that can populate the other
contexts from metadata deployments.

Since this involves injection/dependency of configuration
into other objects this correctly belongs in the Controller.

i.e. At runtime, yes it is ok to do
MetaData.getAnnotation() for simple configuration
but at deployment time it requires resolution of dependencies
some of which will described on the annotation itself.

If you don't believe me, think about what happens when
you redeploy the metadata deployment that contains a default.
configuration.
Shouldn't this "redeploy" all the deployments that use this
to update to the new value?

Also, such a redeployment is necessary if user defined metadata could
affect the classloading model when the classes/annotations, etc.
change.

I believe you, but its not clear how the dependecies are going to be added. If I have simple deployers parsing annotations and descriptors to build the metadata instance graphs, there needs to be a resolution phase for references that can introduce the approriate dependency as a by product of resolving the reference to the ejb, queue, datasource, etc.

[adrian.brock]

I'm not talking about the default datasource

java:/DefaultDS

I'm talking about the default resource-ref binding
(or its annotation equivalent)

<resource-ref>
 <res-ref-name>jdbc/DataSource</res-ref-name>
 <jndi-name>java:/DefaultDS</jndi-name>
</resource-ref>

which can be set at any level and would get "merged" into the ENC.

This could be set at the server scope.

The same thing happens with
1) Class annotation at the class scope
2) XML overrides at the instance scope (if you assume instance
generically means bean instance for POJOs or EJB container of EJB
deployments)

The user still wants to know:
1) What is the ENC for this instance (merged).
2) Where are these values configured in my deployments (what they actually change) which can affect multiple instances depending on the scope.

[adrian.brock]

I believe you, but its not clear how the dependecies are going to be added. If I have simple deployers parsing annotations and descriptors to build the metadata instance graphs, there needs to be a resolution phase for references that can introduce the approriate dependency as a by product of resolving the reference to the ejb, queue, datasource, etc.

P.S. I didn't say it would easy. This is one reason why I didn't
complete the MetaData stuff since it needs some real world
implementation/usage to flush out all the details.

The basics seem easy to me?

real deployer -> decide scopes (mutable and full)
metadata deployer -> populate ad hoc metadata at the defined scope

The part that is hard (especially when you get the kind of
ad hoc, ill thought out rules in the javaee specs) is:

user deployer -> process the metadata from this full scope into some bean
deployment that can take part in the dependency mechanism

The staged deployers help since all the real deployers
(defining the scopes) and metadata deployers (populating the metadata)
are done before the user deployers are run.