Hi Werner,
I'm having what I think is the same problem. I have (a very simplified
xml):
<?xml version="1.0" encoding="UTF-8"?>
<ROOT attr="attr" >
<C>C1</C>
<C>C2</C>
<C>C3</C>
</ROOT>
Using source generated with the following xsd,
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
<xsd:element name="ROOT">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element maxOccurs="unbounded" ref="A"/>
<xsd:element maxOccurs="unbounded" ref="B"/>
<xsd:element maxOccurs="unbounded" ref="C"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="attr" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="A">
<xsd:simpleType>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="B">
<xsd:simpleType>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="C">
<xsd:simpleType>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:element>
</xsd:schema>
The above xml validates with regards to the xsd and I am able to marshal
it.
Now I use a slightly different xsd with an additional element in the
sequence:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
<xsd:element name="ROOT">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="X" type="XType" minOccurs="0"/>
<xsd:choice>
<xsd:element maxOccurs="unbounded" ref="A"/>
<xsd:element maxOccurs="unbounded" ref="B"/>
<xsd:element maxOccurs="unbounded" ref="C"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="attr" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="A">
<xsd:simpleType>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="B">
<xsd:simpleType>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="C">
<xsd:simpleType>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:element>
<xsd:complexType name="XType">
<xsd:attribute name="xname" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:schema>
The xml still validates with regards to the schema (I'm using XMLSpy).
But when I try to marshal I get the following error:
org.exolab.castor.xml.MarshalException: Element with name C passed to
type ROOT in incorrect order; It is not allowed to be the last element
of this sequence!{File: [not available]; line: 4; column: 8}
at
org.exolab.castor.xml.Unmarshaller.convertSAXExceptionToMarshalException
(Unmarshaller.java:794)
at
org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:760)
at ch.castor.example.tests.TestChoice.main(TestChoice.java:26)
Caused by: ValidationException: Element with name C passed to type ROOT
in incorrect order; It is not allowed to be the last element of this
sequence!
at
org.exolab.castor.xml.util.XMLClassDescriptorImpl.checkDescriptorForCorr
ectOrderWithinSequence(XMLClassDescriptorImpl.java:340)
at
org.exolab.castor.xml.MarshalFramework$InternalXMLClassDescriptor.checkD
escriptorForCorrectOrderWithinSequence(MarshalFramework.java:785)
at
org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.jav
a:1943)
at
org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.jav
a:1420)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElemen
t(AbstractSAXParser.java:501)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.s
canStartElement(XMLDocumentFragmentScannerImpl.java:1357)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$F
ragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2740)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLD
ocumentScannerImpl.java:647)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.s
canDocument(XMLDocumentFragmentScannerImpl.java:508)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML1
1Configuration.java:807)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML1
1Configuration.java:737)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.jav
a:107)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Abstr
actSAXParser.java:1205)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.pars
e(SAXParserImpl.java:522)
at
org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:748)
... 1 more
However the xml:
<?xml version="1.0" encoding="UTF-8"?>
<ROOT attr="attr" >
<C>C1</C>
</ROOT>
Validates and can be marshalled.
Any thoughts on this? Have I done something wrong?
Cheers,
Jennifer
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent: Friday, 31. October, 2008 10:33
To: [email protected]
Subject: Re: [castor-user] Re: problem with xs:choice order indicator
Hi Jeffrey,
[EMAIL PROTECTED] wrote:
> Hi Werner,
>
> Thanks for your time here. I tried that property & properties file
with
> the new attribute but had no change in results.
Which is odd, as the stack trace in the first email indicates that this
is a problem with strict order of sequence, and the property turns this
feature off. I guess I will need a Jira issue where you attach all
relevant files for me, incl. builder properties, etc. But please try to
keep things am minimal as possible.
> We'd certainly prefer to
> use the choice element as you'd assume, which would be mutually
exclusive.
> it actually looks as if setting maxOccurs at the choice level will
> write more than one type if they are provided in the xml
>
> i.e.,
>
> providing
> ...
> <foo>1</foo>
> <foo>2</foo>
> <bar>3</bar>
> ..
> to
> .
> <xs:choice maxOccurs="unbounded">
> <xs:element name="foo" type="xs:string" />
> <xs:element name="bar" type="xs:string" />
> </xs:choice>
>
> yields:
>
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler -
#startElement:
> foo
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #characters:
> 1 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler -
> #endElement: foo
>
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler -
#startElement:
> foo
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #characters:
> 2 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler -
> #endElement: foo
>
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler -
#startElement:
> bar
> 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler - #characters:
> 3 2008-10-30 11:55:17,726 main DEBUG xml.UnmarshalHandler -
> #endElement: bar
>
>
> This above choice level behaiour is kind of a side note. If you do
> have an opportunity to look into how we may succesfully set the
> element level of a choice without the maxOccurs of the choice, that
> would be a winner for us.
I'll try my best, but I need something to 'play' with.
>
>
> Best,
>
> Jeff
>
>
>
>
>
>
> Werner Guttmann <[EMAIL PROTECTED]>
> 10/30/2008 03:38 AM
> Please respond to
> [email protected]
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: [castor-user] Re: problem with xs:choice order indicator
>
>
>
>
>
>
> Hi Jeffrey,
>
> I do remember that - now and then - issues have been reported related
> to unbounded choices and broken validation code. I will be having a
> detailed look later on this week, but I simply do not have the time to
> do this right now.
>
> There's only one work-around I can suggest: can you - i a custom
> castor.properties file - please override the following property:
>
> # Property that allows to specify whether the validation for #
> <xs:integer> should accept the old 'int/Integer' members # as
> well; default to false.
> #
> org.exolab.castor.xml.lenient.integer.validation=true
>
> and see whether that makes a difference ?
>
> Regards
> Werner Guttmann
>
> [EMAIL PROTECTED] wrote:
>> ----- Forwarded by Jeffrey Kramer/USA/DDS on 10/29/2008 04:53 PM
>> -----
>>
>>
>>
>>
>> Hi Werner,
>>
>> I should have mentioned initially this is Castor version 1.2 on a
> windows
>> xp machine with java version 1.5.0_16.
>>
>> It looks like the major question here is how Castor is handling the
>> attributes of the Choice elements & it's respective nested simple
> elements
>>
>> under the following assumption:
>>
>> The expression <xs:choice maxOccurs="unbounded"> allows the contents
>> to
> be
>> repeated one or more times.
>> The expression <xs:element name="X" maxOccurs="unbounded"> allows the
>> single element to be repeated one or more times
>>
>>
>> For xml containing:
>>
>> ...
>> <foo>1</foo>
>> <foo>2</foo>
>> <office>NY</office>
>> ...
>>
>> I've observed the following cases:
>>
>>
>> (1) maxOccurs attribute set in choice element
>>
>> <xs:choice maxOccurs="unbounded">
>> <xs:element name="foo" type="xs:string" minOccurs="1" />
>> </xs:choice>
>>
>>
>> => works without error
>>
>> (2) Here the case where the choice element does not have a maxOccurs
>> attribute set ( default = 1)
>>
>> <xs:choice >
>> <xs:element name="foo" type="xs:string" minOccurs="1"
>> maxOccurs="unbounded" />
>> </xs:choice>
>> <office>NY</office>
>>
>> => throws the following exception:
>>
>> -- org.exolab.castor.xml.MarshalException: Element with name foo
>> passed
> to
>> type companyEmployee in incorrect order; expected element with name
>> 'office' or any other optional element declared prior to it.{File:
>> [not available]; line: 9; column: 7}
>>
>> This 2nd case is actually a format we're interested in using. Any
>> insight or suggestion you may be able to provide would be greatly
>> appreciated.
>>
>> Thanks,
>>
>> Jeff
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
