"adrian(a)jboss.org" wrote : | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974867#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...