JBXB-114, model group issues

[starksm64]

What can we do with legacy documents that map to new model groups, but violate the group element ordering as is the case with the JBXB-114 and jboss_4_2.dtd environment reference model group?

The problem is that the jboss_4_2.dtd intermixes elements from the jboss_5_0.xsd jboss:jndiEnvironmentRefsGroup with other elements. For example, the security-identity element is in between service-ref and resource-ref:

<!ELEMENT session (ejb-name , jndi-name? , local-jndi-name?, call-by-value?,
 exception-on-rollback?, timer-persistence?, configuration-name?, invoker-bindings?,
 security-proxy? , ejb-ref* , ejb-local-ref* , service-ref*, security-identity? ,
 resource-ref* , resource-env-ref*, message-destination-ref* , clustered? ,
 cluster-config?, method-attributes?, depends*,
 ior-security-config?, port-component*, ejb-timeout-identity?)>

This causes two different JBossEnvironmentRefsGroupMetaData instances to be created and when the second instance is set on the session bean it fails because the setter has a guard to validate the group is not being set more than once.

In reality we want to use the same group instance to collect the elements until the parent element end is seen. I'm sure this would make the parsing code even more of a mess though. This could be handled by the setJndiEnvironmentRefsGroup method merging the disparate groups into one. The binding code is not responsible for validation after all.

[aloubyansky]

The jboss:jndiEnvironmentRefsGroup may appear only once, right? Continuing the group after security-identity would actually violate the schema?
Maybe we could have some kind of smart error handler to workaround this issue. But that would look more like a hack.

[aloubyansky]

It has to be like model group all but should allow model groups intermixed with elements.

[starksm64]

The jboss:jndiEnvironmentRefsGroup may appear only once, right? Continuing the group after security-identity would actually violate the schema?

Yes, and yes. I just don't know if this is worth trying to hack at the xb layer. It can be handled by the setter.