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
