3 Replies Latest reply on Oct 27, 2007 3:51 AM by starksm64

    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.