You are welcome. But please note that this restricts your validation logic with all sequences. I do appreciate that this is a work-around for this bug (and that's what it looks like), though.
Werner Jennifer Thorsley wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
