0 Replies Latest reply on Dec 16, 2009 4:23 AM by jaikiran

    Test multiline code blocks with wiki markup

    jaikiran
      After upgrading jboss-metadata-ejb to the latest jboss-metadata-common (has EE6 specific things), i am seeing some regressions through jboss-metadata-ejb testsuite. Specifically, the JBoss50XSDBindingUnitTestCase and JBoss51XSDBindingUnitTestCase which validate that the .xsd file and its metadata binding(s) are in sync. The testcases that fail:
      
      {code}
      Failed tests:
        testJBoss51(org.jboss.test.metadata.binding.JBoss51XSDBindingUnitTestCase)
        testJBoss50(org.jboss.test.metadata.binding.JBoss50XSDBindingUnitTestCase)
      {code}
      
      The failures are (it's the same for both the testcases, so just pasting only one of those):
      {code}
      2009-12-15 18:44:35,756 TRACE [org.jboss.test.metadata.binding.JBoss51XSDBindingUnitTestCase] assertEquivalent complex types: {http://www.jboss.com/xml/ns/javaee}message-destinationType
      2009-12-15 18:44:35,756 TRACE [org.jboss.test.metadata.binding.JBoss51XSDBindingUnitTestCase] sequence
      2009-12-15 18:44:35,756 TRACE [org.jboss.test.metadata.binding.JBoss51XSDBindingUnitTestCase] expected particles:
      - sequence
      - {http://www.jboss.com/xml/ns/javaee}message-destination-name
      - choice
      actual particles:
      - wildcard
      - {http://www.jboss.com/xml/ns/javaee}message-destination-name
      - {http://www.jboss.com/xml/ns/javaee}jndi-name
      - {http://www.jboss.com/xml/ns/javaee}mapped-name
      - {http://www.jboss.com/xml/ns/javaee}lookup-name
      {code}
      {code}
      -------------------------------------------------------------------------------
      Test set: org.jboss.test.metadata.binding.JBoss51XSDBindingUnitTestCase
      -------------------------------------------------------------------------------
      Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.949 sec <<< FAILURE!
      testJBoss51(org.jboss.test.metadata.binding.JBoss51XSDBindingUnitTestCase)  Time elapsed: 0.924 sec  <<< FAILURE!
      junit.framework.AssertionFailedError: ModelGroupBinding particles total expected 3 but was 5
           at junit.framework.Assert.fail(Assert.java:47)
           at org.jboss.test.metadata.binding.SchemaBindingValidationTest.assertEquivalent(SchemaBindingValidationTest.java:529)
           at org.jboss.test.metadata.binding.SchemaBindingValidationTest.assertEquivalent(SchemaBindingValidationTest.java:352)
           at org.jboss.test.metadata.binding.SchemaBindingValidationTest.assertEquivalent(SchemaBindingValidationTest.java:318)
           at org.jboss.test.metadata.binding.SchemaBindingValidationTest.assertEquivalent(SchemaBindingValidationTest.java:261)
           at org.jboss.test.metadata.binding.SchemaBindingValidationTest.assertEquivalent(SchemaBindingValidationTest.java:210)
           at org.jboss.test.metadata.binding.SchemaBindingValidationTest.assertEquivalent(SchemaBindingValidationTest.java:137)
           at org.jboss.test.metadata.binding.JBoss51XSDBindingUnitTestCase.testJBoss51(JBoss51XSDBindingUnitTestCase.java:63)
      {code}
      
      The root cause, is that the some of the types in jboss_5_0.xsd (and jboss_5_1.xsd) ultimately bind to org.jboss.metadata.javaee.spec.MessageDestinationMetaData which earlier was:
      
      {code}
      @XmlType(name="message-destinationType", propOrder={"descriptionGroup", "messageDestinationName", "jndiName", "mappedName"})
      public class MessageDestinationMetaData ....
      {code}
      
      but now is
      {code} 
      @XmlType(name="message-destinationType", propOrder={"descriptionGroup", "messageDestinationName", "jndiName", "mappedName", "lookupName"})
      public class MessageDestinationMetaData ...
      
      {code}
      
      Notice the new attribute "lookupName" which is not available in the jboss_5_0.xsd and jboss_5_1.xsd. There are other similar changes in jboss-metadata-common which now leave these xsds incompatible with the binding classes.
      
      How do we tackle these? Changing the existing xsd(s) won't be an option. Probably we should just have left the existing metadata binding classes as-is and maybe introduce new binding classes for EE6 specific things. Something like:
      
      {code}
      @XmlType(name="message-destinationType", propOrder={"descriptionGroup", "messageDestinationName", "jndiName", "mappedName", "lookupName"})
      public class EE6MessageDestinationMetaData extends MessageDestinationMetaData
      {code}