castor
  1. castor
  2. CASTOR-1150

castor fails to unmarshall valid instance of sequence-of-choice schema

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.6
    • Fix Version/s: 1.2
    • Component/s: XML
    • Labels:
      None
    • Environment:
      Windows XP, Java 1.4.1
    • Testcase included:
      yes
    • Number of attachments :
      5

      Description

      The build.xml ant script in the attached zip file:

      1. generates a java object model from the following schema:

      <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
      <xs:element name="SequenceOfChoice" type="SequenceOfChoice" abstract="false" nillable="false"/>
      <xs:complexType name="SequenceOfChoice" abstract="false" mixed="false">
      <xs:sequence maxOccurs="unbounded">
      <xs:choice>
      <xs:element name="ChoiceOne" type="xs:string" nillable="false"/>
      <xs:element name="ChoiceTwo" type="xs:string" nillable="false"/>
      </xs:choice>
      </xs:sequence>
      </xs:complexType>
      </xs:schema>

      2. and then runs a JUnit test that asserts that the following valid instance of the schema given above can be unmarshalled:

      <?xml version="1.0" encoding="UTF-8"?>
      <SequenceOfChoice xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="..\..\model-schema.xsd">
      <ChoiceTwo>String</ChoiceTwo>
      <ChoiceOne>String</ChoiceOne>
      </SequenceOfChoice>

      Unmarshalling fails and throws the following exception:

      The container object (model.SequenceOfChoiceChoice) cannot accept the child object associated with the element 'ChoiceOne' because the container is already full!

      {file: [not available]; line: 4; column: 16}

      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:671)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:565)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:748)
      at model.SequenceOfChoiceTest.testUnmarshalSequenceOfChoice(SequenceOfChoiceTest.java:48)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at junit.framework.TestCase.runTest(TestCase.java:154)
      at junit.framework.TestCase.runBare(TestCase.java:127)
      at junit.framework.TestResult$1.protect(TestResult.java:106)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.framework.TestResult.run(TestResult.java:109)
      at junit.framework.TestCase.run(TestCase.java:118)
      at junit.framework.TestSuite.runTest(TestSuite.java:208)
      at junit.framework.TestSuite.run(TestSuite.java:203)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:474)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:342)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:194)
      Caused by: ValidationException: The container object (model.SequenceOfChoiceChoice) cannot accept the child object associated with the element 'ChoiceOne' because the container is already full!
      at org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:1667)
      at org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:1338)
      at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
      at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
      at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:657)
      ... 18 more
      Caused by: ValidationException: The container object (model.SequenceOfChoiceChoice) cannot accept the child object associated with the element 'ChoiceOne' because the container is already full!
      at org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:1667)
      at org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:1338)
      at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
      at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
      at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:657)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:565)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:748)
      at model.SequenceOfChoiceTest.testUnmarshalSequenceOfChoice(SequenceOfChoiceTest.java:48)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at junit.framework.TestCase.runTest(TestCase.java:154)
      at junit.framework.TestCase.runBare(TestCase.java:127)
      at junit.framework.TestResult$1.protect(TestResult.java:106)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.framework.TestResult.run(TestResult.java:109)
      at junit.framework.TestCase.run(TestCase.java:118)
      at junit.framework.TestSuite.runTest(TestSuite.java:208)
      at junit.framework.TestSuite.run(TestSuite.java:203)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:474)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:342)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:194)
      Caused by: ValidationException: The container object (model.SequenceOfChoiceChoice) cannot accept the child object associated with the element 'ChoiceOne' because the container is already full!
      at org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:1667)
      at org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.java:1338)
      at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
      at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
      at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:657)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:565)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:748)
      at model.SequenceOfChoiceTest.testUnmarshalSequenceOfChoice(SequenceOfChoiceTest.java:48)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at junit.framework.TestCase.runTest(TestCase.java:154)
      at junit.framework.TestCase.runBare(TestCase.java:127)
      at junit.framework.TestResult$1.protect(TestResult.java:106)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.framework.TestResult.run(TestResult.java:109)
      at junit.framework.TestCase.run(TestCase.java:118)
      at junit.framework.TestSuite.runTest(TestSuite.java:208)
      at junit.framework.TestSuite.run(TestSuite.java:203)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:474)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:342)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:194)

      1. broken.xsd
        0.7 kB
        Michael Thome
      2. C1150_20071030.txt
        6 kB
        Steven Dolg
      3. patch.c1150.20060728.txt
        1 kB
        Werner Guttmann
      4. patch.c1150.20061002.txt
        43 kB
        Werner Guttmann

        Issue Links

          Activity

          Hide
          James Webster added a comment -

          A solution to this problem is to move the maxOccurs="unbounded" from the xsd:sequence to the xsd:choice. This also eliminates the need for the xsd:sequence, unless you are going to put other elements into the sequence.

          <xs:complexType name="SequenceOfChoice" abstract="false" mixed="false">
          <xs:sequence>
          <xs:choice maxOccurs="unbounded">
          <xs:element name="ChoiceOne" type="xs:string" nillable="false"/>
          <xs:element name="ChoiceTwo" type="xs:string" nillable="false"/>
          </xs:choice>
          </xs:sequence>
          </xs:complexType>

          Show
          James Webster added a comment - A solution to this problem is to move the maxOccurs="unbounded" from the xsd:sequence to the xsd:choice. This also eliminates the need for the xsd:sequence, unless you are going to put other elements into the sequence. <xs:complexType name="SequenceOfChoice" abstract="false" mixed="false"> <xs:sequence> <xs:choice maxOccurs="unbounded"> <xs:element name="ChoiceOne" type="xs:string" nillable="false"/> <xs:element name="ChoiceTwo" type="xs:string" nillable="false"/> </xs:choice> </xs:sequence> </xs:complexType>
          Hide
          Plamen Atanassov added a comment -

          This bug appears in 0.9.7 as well. The exception is the same. Worse, the proposed solution also throws the same exception.

          Show
          Plamen Atanassov added a comment - This bug appears in 0.9.7 as well. The exception is the same. Worse, the proposed solution also throws the same exception.
          Hide
          Felix Ritter added a comment -

          This bug did not appear in version 0.9.5.3!
          Does anybody have an idea when this bug will be fixed?

          Show
          Felix Ritter added a comment - This bug did not appear in version 0.9.5.3! Does anybody have an idea when this bug will be fixed?
          Hide
          Greg Allen added a comment -

          Would be great if this could be fixed for 0.9.9M2

          Show
          Greg Allen added a comment - Would be great if this could be fixed for 0.9.9M2
          Hide
          Greg Allen added a comment -

          workaround is to put the choice in a group, and have maxOccurs="unbounded" on the group rather than the choice.

          Show
          Greg Allen added a comment - workaround is to put the choice in a group, and have maxOccurs="unbounded" on the group rather than the choice.
          Hide
          Edwin Platteel added a comment -

          Is there any information on a fix version or progress on this matter?

          Show
          Edwin Platteel added a comment - Is there any information on a fix version or progress on this matter?
          Hide
          Michelle Pollard added a comment -

          The issue still exists in 1.0. I've reverted to 0.9.3.19 which does not have the issue, but a fix would be better. Any updates?

          Show
          Michelle Pollard added a comment - The issue still exists in 1.0. I've reverted to 0.9.3.19 which does not have the issue, but a fix would be better. Any updates?
          Hide
          Werner Guttmann added a comment -

          Michelle, can you please push a short email to the dev/user list and make yourself heard there, iow post a quick statement about the problem and the fact that ot still exists. In addition, if you had a working sample that showcases the problem at hand, I'd appreciate if you could attach the required files to this issue. And if you managed to follow the guidelines at http://castor.org/how-to-submit-an-xml-bug.html, that would be even better.

          Show
          Werner Guttmann added a comment - Michelle, can you please push a short email to the dev/user list and make yourself heard there, iow post a quick statement about the problem and the fact that ot still exists. In addition, if you had a working sample that showcases the problem at hand, I'd appreciate if you could attach the required files to this issue. And if you managed to follow the guidelines at http://castor.org/how-to-submit-an-xml-bug.html , that would be even better.
          Hide
          Guillaume Jeudy added a comment -

          The issue is still occurring in 1.0, any plans to fix this in the near future?

          Show
          Guillaume Jeudy added a comment - The issue is still occurring in 1.0, any plans to fix this in the near future?
          Hide
          Michael Thome added a comment -

          I observe that in various tested versions up through 1.0 (I haven't tried one that worked properly), any use of <choice maxOccurs="unbounded"> fails.

          My use is slightly different and results in uncompilable code. Here's my schema fragment:
          <complexType name="FeatureType">
          <choice minOccurs="1" maxOccurs="unbounded">
          <element name="circle" type="tfr:CircleType"></element>
          <element name="polygon" type="tfr:PolygonType"></element>
          </choice>
          </complexType>

          <complexType name="TfrType">
          <sequence>
          <!-- -->
          <element name="feature" type="tfr:FeatureType" maxOccurs="1" minOccurs="0"/>
          </sequence>
          </complexType>
          <element name="tfr" type="tfr:TfrType">

          Interestingly, castor (1.0) generates TfrType.java with a member field
          private Feature _feature;
          instead of
          private FeatureType _feature;

          Obviously, since it doesn't generate a class named Feature, the resulting code is not compilable.

          I'd also like to point out that merely altering the schema to make it work with castor isn't a viable solution when we're writing client code for someone else's schema - I am often required to use only the published schema of a service, and the <choice maxOccurs="1"> syntax is both in common use and seems to be officially documented (see, for example, the sample schema chode immediately ABOVE this reference http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#d0e7923 )

          Show
          Michael Thome added a comment - I observe that in various tested versions up through 1.0 (I haven't tried one that worked properly), any use of <choice maxOccurs="unbounded"> fails. My use is slightly different and results in uncompilable code. Here's my schema fragment: <complexType name="FeatureType"> <choice minOccurs="1" maxOccurs="unbounded"> <element name="circle" type="tfr:CircleType"></element> <element name="polygon" type="tfr:PolygonType"></element> </choice> </complexType> <complexType name="TfrType"> <sequence> <!-- --> <element name="feature" type="tfr:FeatureType" maxOccurs="1" minOccurs="0"/> </sequence> </complexType> <element name="tfr" type="tfr:TfrType"> Interestingly, castor (1.0) generates TfrType.java with a member field private Feature _feature; instead of private FeatureType _feature; Obviously, since it doesn't generate a class named Feature, the resulting code is not compilable. I'd also like to point out that merely altering the schema to make it work with castor isn't a viable solution when we're writing client code for someone else's schema - I am often required to use only the published schema of a service, and the <choice maxOccurs="1"> syntax is both in common use and seems to be officially documented (see, for example, the sample schema chode immediately ABOVE this reference http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#d0e7923 )
          Hide
          Werner Guttmann added a comment -

          Michael, I have just used the source generator on the current codebase in the SVN repo (trunk), and for me the classes generated are consistent and include a class named Feature. Are you using a custom castorbuilder.properties to manually override some settings, or do you stay with the defaults ?

          Show
          Werner Guttmann added a comment - Michael, I have just used the source generator on the current codebase in the SVN repo (trunk), and for me the classes generated are consistent and include a class named Feature. Are you using a custom castorbuilder.properties to manually override some settings, or do you stay with the defaults ?
          Hide
          Werner Guttmann added a comment -

          And that is, I have used your schema as included above (with two minor alterations, replacing the element types for circle and polygon with xs:string to be able to generate the sources.

          Show
          Werner Guttmann added a comment - And that is, I have used your schema as included above (with two minor alterations, replacing the element types for circle and polygon with xs:string to be able to generate the sources.
          Hide
          Werner Guttmann added a comment -

          And more generally, can anybody please enlighten me as to why having the maxOccurs="unbounded" on the <xs:choice> is not considered to be an option, given that it is a valid workaround ?

          Show
          Werner Guttmann added a comment - And more generally, can anybody please enlighten me as to why having the maxOccurs="unbounded" on the <xs:choice> is not considered to be an option, given that it is a valid workaround ?
          Hide
          Michael Thome added a comment -

          Ah - I neglected to mention that I use org.exolab.castor.builder.javaclassmapping=type .
          I do also use org.exolab.castor.builder.nspackages=..., but all else is default.

          I do not use element classmapping because several of my other schemas runs into problems with ambiguous element name (so the generated classes collide)

          I'll also attach my schema file, fwiw.

          Show
          Michael Thome added a comment - Ah - I neglected to mention that I use org.exolab.castor.builder.javaclassmapping=type . I do also use org.exolab.castor.builder.nspackages=..., but all else is default. I do not use element classmapping because several of my other schemas runs into problems with ambiguous element name (so the generated classes collide) I'll also attach my schema file, fwiw.
          Hide
          Michael Thome added a comment -

          Here's an actual sample schema

          Show
          Michael Thome added a comment - Here's an actual sample schema
          Hide
          Werner Guttmann added a comment -

          Michael, can you please attach your castorbuilder.properties file as well as a sample XML document I could use for unmarshalling ?

          Show
          Werner Guttmann added a comment - Michael, can you please attach your castorbuilder.properties file as well as a sample XML document I could use for unmarshalling ?
          Hide
          Werner Guttmann added a comment -

          And if you want me to use your schema as is, I'd need the compleyType defs for the other types as well ... otherwise, I'll change the types of circle and polygon to xsd:string.

          Show
          Werner Guttmann added a comment - And if you want me to use your schema as is, I'd need the compleyType defs for the other types as well ... otherwise, I'll change the types of circle and polygon to xsd:string.
          Hide
          Werner Guttmann added a comment -

          Patch that fixes the resolution of the class name in 'type' mode. I'd appreciate any feedback.

          Show
          Werner Guttmann added a comment - Patch that fixes the resolution of the class name in 'type' mode. I'd appreciate any feedback.
          Hide
          Werner Guttmann added a comment -

          Above patch fixes the problem as reported by Michael wrt sourec code generation in 'type' mode and wrong class name resolution (Feature instead of FeatureType).

          Show
          Werner Guttmann added a comment - Above patch fixes the problem as reported by Michael wrt sourec code generation in 'type' mode and wrong class name resolution (Feature instead of FeatureType).
          Hide
          Werner Guttmann added a comment -

          Michael, any changes of attaching a complete XML schema, incl. e.g. type defs for the classed referenced in your broken.xsd ?

          Show
          Werner Guttmann added a comment - Michael, any changes of attaching a complete XML schema, incl. e.g. type defs for the classed referenced in your broken.xsd ?
          Hide
          Michael Thome added a comment -

          Sorry - I thought this issue was closed by your patch. The actual types do not appear to matter - your sample with the missing types replaced with xsd:string is sufficient.

          Show
          Michael Thome added a comment - Sorry - I thought this issue was closed by your patch. The actual types do not appear to matter - your sample with the missing types replaced with xsd:string is sufficient.
          Hide
          Werner Guttmann added a comment -

          Okay, here's what I will do.

          a) Fix the issue as reported by Michael as part of a separate issue.
          b) Address the 'unbounded' choice issue as part of this issue. Having said that, introducing support for unbounded choices does not really look easy to me. I can see that it has been working in older releases, but with the current codebase, this will not be easy to introduce.

          Show
          Werner Guttmann added a comment - Okay, here's what I will do. a) Fix the issue as reported by Michael as part of a separate issue. b) Address the 'unbounded' choice issue as part of this issue. Having said that, introducing support for unbounded choices does not really look easy to me. I can see that it has been working in older releases, but with the current codebase, this will not be easy to introduce.
          Hide
          Werner Guttmann added a comment -

          Michael, no, the patch provided has not been applied (yet). I am just looking at this after some time (to be honest), and it looks like I will have to split things apart to make this manageable. I can get your sample XML schema to work just fine, so at least this will be th easy part.

          Show
          Werner Guttmann added a comment - Michael, no, the patch provided has not been applied (yet). I am just looking at this after some time (to be honest), and it looks like I will have to split things apart to make this manageable. I can get your sample XML schema to work just fine, so at least this will be th easy part.
          Hide
          Werner Guttmann added a comment -

          Updated patch, with all files deleted that are not relevant for this problem.

          Show
          Werner Guttmann added a comment - Updated patch, with all files deleted that are not relevant for this problem.
          Hide
          Edwin Platteel added a comment -

          Any update on this bug, as we are trying to update to the new Castor version, which we cannot do since this bug is still unresolved?

          Show
          Edwin Platteel added a comment - Any update on this bug, as we are trying to update to the new Castor version, which we cannot do since this bug is still unresolved?
          Hide
          Steven Dolg added a comment -

          Here's a patch that fixes the problems with the testcase provided.
          The XML master and regression test suite both work as before with the changes introduced.

          This is only a minimal change to solve this issue.
          Some additional work for cleanup and/or design improvement is still necessary...

          Show
          Steven Dolg added a comment - Here's a patch that fixes the problems with the testcase provided. The XML master and regression test suite both work as before with the changes introduced. This is only a minimal change to solve this issue. Some additional work for cleanup and/or design improvement is still necessary...
          Hide
          Werner Guttmann added a comment -

          Thanks, Steven. Question to the reporter of this issue and/or the folks watching this issue. Given that more than 1 man day went into the resolution of this bug, I wonder whether anybody would be willing to show her appreciation by donating some cash ?

          Show
          Werner Guttmann added a comment - Thanks, Steven. Question to the reporter of this issue and/or the folks watching this issue. Given that more than 1 man day went into the resolution of this bug, I wonder whether anybody would be willing to show her appreciation by donating some cash ?
          Hide
          Werner Guttmann added a comment -

          Well, well ... no answer is an answer as well .. .

          Show
          Werner Guttmann added a comment - Well, well ... no answer is an answer as well .. .

            People

            • Assignee:
              Steven Dolg
              Reporter:
              Leif Oines
            • Votes:
              10 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 hour, 50 minutes
                1h 50m
                Remaining:
                Remaining Estimate - 1 hour, 50 minutes
                1h 50m
                Logged:
                Time Spent - Not Specified
                Not Specified