[Design of POJO Server] - Re: Updating docs
by scott.stark＠jboss.org
"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#3974867
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974867
17 years, 7 months
[Design of POJO Server] - Re: Updating docs
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote :
| There should be no merging for display to the user, that would
| be pointless.
|
| e.g. If the default DataSource is set in the metadata
| at the deployment level or server level you don't want to merge this into the
| ejb instance view.
| The user cannot change the global default value by modifying a
| single ejb.
|
| This default metadata is in a seperate deployment.
|
| The only merging would be explaining to the user where a
| particular value came from and potentially providing a unified
| editiing tool that explains to them that they are either changing
| a global default or they are overriding it for their particualr
| deployment, instance, etc.
The issue is illustrated by the enc example in that multiple scopes and sources of metadata go into the object that is used to create the javax.naming.Context that will be installed for a given component enc context.
The default DataSource does need to get merged (resolved is a better term, maybe that is the confusion) into the cmp2 metadata. If I have not specified it via an annotation or descriptor, it has to be picked up from an encompassing scope.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974865#3974865
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974865
17 years, 7 months