To merge or not to merge?

[adrian.brock]

I've been thinking about this merging of metadata
between ejb-jar.xml and jboss.xml and I'm not sure we
actually want to do this?

The main reason is that doing so, loses the information
on where the metadata came from.

1) You cannot take the metadata and turn it back into the xml files.
2) You don't know where to direct the user about where to fix something

A simple example is jndi-name in jboss.xml which now has a
corresponding mapped-name in ejb-jar.xml for EJB3

Making these the same property would lose which file it came from.

Given that I want to extend jboss.xml so you can override
"everything" this doesn't look like a good solution.

A better solution would be to make it delegate,
like the following pseudo code.

class DelegateBeanMetaData
{
 String getJndiName()
 {
 String result = jbossXML.getJndiName();
 if (result == null)
 return ejbJarXML.getMappedName();
 }
}

In fact, with the org.jboss.metaData stuff
it would be trivial to implement this provided the metadata
is split up enough.

You just need two MetaDataContexts one for jboss.xml
and one for ejb-jar.xml

Then the query becomes:
JndiBinding binding = MetaData.getMetaData(JndiBinding.class);

[starksm64]

This is what I was referring to previously about a unified api for traversing/merging the various scopes of data. This also intersects with the discussion on how overlapping annotation collections are merged. There is a tradeoff between having a framework that generally can build up something like a JndiBinding vs having to write the merge logic in terms of delgating accessors.

Given n scopes of data of types T1...Tn, and a unfied type T (which usually would be amongst T1...Tn I would expect), the ideal thing would be to have the framework piece together the type instances so that T.x was a merge ot the T1...Tn sources of the property x. How to write this without significat restrictions on how the types relates seems non-trivial at this point.

[adrian.brock]

But I think we are talking about different things, at least from
my understanding of your original post.

There is a need to merge/hide/override at runtime and this
depends upon the type of metadata (it also includes having the
ability to query where the data came from).

The full normalized view should be maintained elsewhere.

When I talk about merging I'm talking about giving the runtime view,
e.g. getting all the resource-refs for a bean (from all levels).

[starksm64]

But I think we are talking about different things, at least from
my understanding of your original post.

There is a need to merge/hide/override at runtime and this
depends upon the type of metadata (it also includes having the
ability to query where the data came from).

Argreed, but runtime usage vs asking where runtime T.x actually came from seem like two different uses of the composite metadata for the type T. One way to get the runtime view would be to collapse the levels into an instance T. Another would be a T facade over delegating accessors/iterators that do the right thing for each property x of T.

The full normalized view should be maintained elsewhere.

I'm not following what you mean by normalized view?

When I talk about merging I'm talking about giving the runtime view,
e.g. getting all the resource-refs for a bean (from all levels).

Yes, that is what I would consider as merging as well.

[adrian.brock]

The full normalized view should be maintained elsewhere.

I'm not following what you mean by normalized view?

The normalized view is all the information coupled with where it is defined
not the merged/denormalized view.

i.e. at runtime you say
"What are the resources for this ejb?"
"What is the transaction timeout for this ejb method?"
which comes from the denormalized view, i.e. you get all the resources
that are relevant for the ejb, or the transaction timeout for that context
(regardless of where it is defined).

Elsewhere you use the normalized view, so the responses will be
different:
"What are the resources for this ejb?"
Will only include those actually defined on the ejb not those
defined at e.g. deployment level for which you would need to ask
the normalized view:
"What are the resources for this deployment?"

Similarly for the transaction timeout. The denormalized should
always give you an answer (even if it is just the timeout defined at
server/domain level).
The normalized view will only give you an answer if something
is defined against that ejb method.

In the normalized view you can ask:
"Is there a transaction timeout for this ejb method?"
"Is there a transaction timeout for this ejb?"
"Is there a transaction timeout for this deployment?"
"Is there a transaction timeout for this server?"
etc.