Java EE unified metadata prototype

[aloubyansky]

I looked into Adrian's metadata prototype for EJB2/3 (which hasn't been committed and isn't available publicly).

- the bindings are done with java annotations and it's based on jbossxb-builder. We will need to release the jbossxb-builder if we decide to follow this approach

- the DDs are supposed to be unmarshalled into different object graphs and then merged, right?

- the binding between Java and XML is exact, i.e. each XML element (even if are not interested in it) will be represented in the Java model, right?

[adrian.brock]

I looked into Adrian's metadata prototype for EJB2/3 (which hasn't been committed and isn't available publicly).

- the bindings are done with java annotations and it's based on jbossxb-builder. We will need to release the jbossxb-builder if we decide to follow this approach

The annotations are out-of-date, they would need updating to the JAXB annotations.

- the DDs are supposed to be unmarshalled into different object graphs and then merged, right?

Unless you know of a way to unmarshal two seperate files into one object mode
simultanously? :-)

- the binding between Java and XML is exact, i.e. each XML element (even if are not interested in it) will be represented in the Java model, right?

I'm assuming that even if JBoss (during deployment) doesn't
use the information then somebody else might. Maybe even in their own deployer?
It also allows for the object model to be changed (programmatically)
and remarshalled back to the xml - something that's currently impossible
(at least for org.jboss.metadata) because the parsing is not reversable.

[aloubyansky]

- the DDs are supposed to be unmarshalled into different object graphs and then merged, right?

Unless you know of a way to unmarshal two seperate files into one object mode
simultanously? :-)

That was one of the goals for ObjectModelFactory API. Although the parsing code based on that we currently have is quite messy...
Taking the SchemaBinding maybe it would be possible to write custom particle handlers or add a better support for this to XB itself.

I'm assuming that even if JBoss (during deployment) doesn't
use the information then somebody else might. Maybe even in their own deployer? It also allows for the object model to be changed (programmatically)
and remarshalled back to the xml - something that's currently impossible
(at least for org.jboss.metadata) because the parsing is not reversable.

There could be something like an adapter to hide structural differences between the XSD and the Java model.
But I guess you were trying to follow the XSD structure in Java object model and keep it as close as 1-to-1?

[bill.burke]

Instead of having a metadata bridge between these two projects, why not just merge the metamodels? And have both containers use the same classes? If this is an option, I do suggest a new package name so that if Carlo and company need to backmerge something, they won't conflict with JBoss 4.2.

[aloubyansky]

Instead of having a metadata bridge between these two projects, why not just merge the metamodels? And have both containers use the same classes? If this is an option, I do suggest a new package name so that if Carlo and company need to backmerge something, they won't conflict with JBoss 4.2.

You mean EJB2 and EJB3 use the same metadata classes? That's the goal, AFAIK. At least in JBoss5.

[adrian.brock]

Instead of having a metadata bridge between these two projects, why not just merge the metamodels?

That's what I did, they both use the same model.
The bridge just means we don't have to go through all the old
EJB2 classes, clustering classes, etc. and change them (potentially breaking them :-)

But more importantly, these classes are required for any user that wrote their own
interceptor for our EJB2 container.