JBossMetaData merge/override rules

[aloubyansky]

There are at least two sources of metadata: annotations and xml. Whatever approach we choose to represent them, we have to define which information is added (i.e. overriding metadata complements the original) during the merge and which one is completely redefined by the overriding metadata.
For example, in case of security, should the permissions from the XML (if present) replace the permissions defined with annotations completely or extend them?
I think, in general, the answer may depend on the type of metadata in question?
There maybe even a special annotation/xml element which would say how the merge should be done? Or maybe even result in a deployment error for something that must not be overriden? Anyway, let's define the defaults.
I've been writing some tests for every metadata type. But I am still not sure about some of them and would like to clarify.

In simple words for the following types what should be a complete replacement and what should be merged as "addAll()" overriding data with the same key (customizing). I added (addAll) where it seems to me it should be.

From JBossEnterpriseBeanMetaData
- InvokerBindingsMetaData (allAll)
- IORSecurityConfigMetaData
- JBossEnvironmentRefsGroupMetaData (addAll?)
- MethodAttributesMetaData (addAll)
- AnnotationsMetaData
- IgnoreDependencyMetaData (addAll)
- PoolConfigMetaData (addAll)
- JndiRefsMetaData (addAll)

From JBossSessionBeanMetaData
- BusinessLocalsMetaData
- BusinessRemotesMetaData
- InitMethodsMetaData
- RemoveMethodsMetaData
- AroundInvokesMetaData
- LifecycleCallbacksMetaData
- LifecycleCallbacksMetaData
- SecurityRoleRefsMetaData
- List remoteBindings
- ClusterConfigMetaData
- PortComponent
- SecurityIdentityMetaData
- CacheConfigMetaData

From JBossEntityBeanMetaData
- CMPFieldsMetaData (should it be ever overriden?)
- QueriesMetaData (only cutomization of the existing)
- CacheInvalidationConfigMetaData (customize existing)

From JBossMessageDrivenBeanMetaData
- ActivationConfigMetaData (addAll)

From JBossConsumerBeanMetaData
The following should probably be changed to Maps defining the keys for the types to make it easier identify the same metadata piece?
private List messageProperties = null;
private List producers = null;
private List localProducers = null;

From JBossMetaData
- RelationsMetaData (addAll)
- LoaderRepositoryMetaData (addAll)
- WebservicesMetaData (addAll)
- JBossEnterpriseBeansMetaData (addAll)
- ResourceManagersMetaData (addAll)
- InvokerProxyBindingsMetaData (addAll)
- ContainerConfigurationsMetaData (addAll)
- InterceptorsMetaData
- Map<String, RunAsIdentityMetaData> runAsIdentity

From JBossAssemblyDeploymentDescriptor
- SecurityRolesMetaData
- MethodPermissionsMetaData (addAll)
- ContainerTransactionsMetaData (addAll)
- InterceptorBindingsMetaData
- MessageDestinationsMetaData
- ExcludeListMetaData
- ApplicationExceptionsMetaData


In a number of types there are fields of primitive boolean types. It may make sense to switch to the wrapper to differentiate between the default and non-set value.

[wolfc]

This is the relevant part for interceptors:

"EJB 3.0 12.8.2" wrote:
The binding of interceptors to classes is additive. If interceptors are bound at the class-level and/or default-level as well as at the method-level, both class-level and/or default-level as well as method-level interceptors will apply. The deployment descriptor may be used to augment the interceptors and interceptor methods defined by means of annotations. When the deployment descriptor is used to augment the interceptors specified in annotations, the interceptor methods specified in the deployment descriptor will be invoked after those specified in annotations, according to the ordering specified in sections 12.3.1 and 12.4.1. The interceptor-order deployment descriptor element may be used to override this ordering.

[starksm64]

In general the annotation based metadata is not authoritative and should be overridden. Carlo has some examples of where it needs to be additively merged rather than the xml overriding annotations.

One example of a problem I have seen is an annotation mappedName overriding a jboss descriptor jndi-name. That is incorrect.

So what are the options?
(addAll) - the "override" metadata is simply replaces the "original" metadata?
(customizing) - the "override" metadata is merged with the "original" metadata with the override fields overriding the original?

For the (customizing) behavior, this typically will need to be done recursively. Both override and original will have references metadata for example that needs to be merged down to the reference level.