Hi Werner, Adding 'org.exolab.castor.xml.lenient.sequence.order=true' to my castor.properties file fixed the problem!
Thank you, Jennifer -----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Friday, 31. October, 2008 11:55 To: [email protected] Subject: Re: [castor-user] Re: problem with xs:choice order indicator Hi Jennifer, What happens in your case if you enable lenient sequence oder validation ? Regards Werner Jennifer Thorsley wrote: > 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.convertSAXExceptionToMarshalExcepti > on > (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.checkDescriptorForCo > rr > ectOrderWithinSequence(XMLClassDescriptorImpl.java:340) > at > org.exolab.castor.xml.MarshalFramework$InternalXMLClassDescriptor.chec > kD > escriptorForCorrectOrderWithinSequence(MarshalFramework.java:785) > at > org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.j > av > a:1943) > at > org.exolab.castor.xml.UnmarshalHandler.startElement(UnmarshalHandler.j > av > a:1420) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElem > en > 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(XM > LD > 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(XM > L1 > 1Configuration.java:807) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XM > L1 > 1Configuration.java:737) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.j > av > a:107) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Abs > tr > actSAXParser.java:1205) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.pa > rs > 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 > > --------------------------------------------------------------------- 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
