castor

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)

Attachments

  1. XML File
    broken.xsd
    28/Jul/06 3:05 PM
    0.7 kB
    Michael Thome
  2. Text File
    C1150_20071030.txt
    30/Oct/07 11:40 AM
    6 kB
    Steven Dolg
  3. Text File
    patch.c1150.20060728.txt
    28/Jul/06 4:30 PM
    1 kB
    Werner Guttmann
  4. Text File
    patch.c1150.20061002.txt
    02/Oct/06 4:53 PM
    43 kB
    Werner Guttmann

Issue Links

This issue is related to:
CASTOR-1601 Problem deriving type name in 'type' mode .... Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Michael Thome added a comment -

Here's an actual sample schema

Show
Michael Thome added a comment - Here's an actual sample schema
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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

Vote (10)
Watch (10)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
1h 50m
Original Estimate - 1 hour, 50 minutes
Remaining:
1h 50m
Remaining Estimate - 1 hour, 50 minutes
Logged:
Not Specified
Time Spent - Not Specified
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.