Whilst I have not had the time to look at this Jira issue yet, I wonder why following the bug submission guidelines available at
http://www.castor.org/how-to-submit-an-xml-bug.html is so hard to follow .. ;-). I really appreciate your effort(s), but uploading an Eclipse project (incl. e.g. binaries) does not really help. I always thought that the templates we provide are a perfect starting point for creating a bug submission. Given the (highish) number of people (still) insisting on attaching Ant/Eclipse projects, I wonder whether there's anything missing that simply is not obvious to us. Regards Werner PS I hope you don't take any offence by my reply. It looks like your (kind) Jira attachement triggered something inside of me .. ;-) Justin Permar wrote: > I have created a Jira issue here: > > > > http://jira.codehaus.org/browse/CASTOR-1984 > > > > I’ve also posted an attachment of an ant/eclipse project that reproduces > the problem. Thank you for looking into this! > > > > ---------------------------------------------- > > Justin Permar > > Research Programmer > > Department of Biomedical Informatics > > The Ohio State University > > > > *From:* Justin Permar [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, May 22, 2007 10:32 AM > *To:* [email protected] > *Subject:* RE: [castor-user] code generation: schema type restriction > "re-defines" the type of an attribute from the base type > > > > Thanks for your response Werner. I’m working on creating a small ant > project and schema that produces the problem now. I’ll create a Jira > issue shortly. > > > > ---------------------------------------------- > > Justin Permar > > Research Programmer > > Department of Biomedical Informatics > > The Ohio State University > > > > *From:* Werner Guttmann [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, May 22, 2007 9:40 AM > *To:* [email protected] > *Subject:* AW: [castor-user] code generation: schema type restriction > "re-defines" the type of an attribute from the base type > > > > Justin, > > > > I really need to look into this in more detail. Can you please create a > new Jira issue at http://jira.codehaus.org/browse/CASTOR, and attach a > minimal XML schema for me to be able to reproduce environment. In > addition, I’d appreciate if you attached e.g. builder properties, XML > sample document, …. > > > > Werner Guttmann > > > > PS Thanks for going through the effort to describe your problem. I am > sure all of this will find its way into the Jira issue as well .. ;-). > > > > ------------------------------------------------------------------------ > > *Von:* Justin Permar [mailto:[EMAIL PROTECTED] > *Gesendet:* Dienstag, 22. Mai 2007 05:40 > *An:* [email protected] > *Betreff:* [castor-user] code generation: schema type restriction > "re-defines" the type of an attribute from the base type > > > > All, > > > > I am using Castor to generate classes directly from a rather large and > complex schema. I use automatic conflict resolution set to true as part > of the following binding properties: > > > > org.exolab.castor.builder.javaclassmapping=type > > org.exolab.castor.builder.javaVersion=5.0 > > org.exolab.castor.builder.automaticConflictResolution=true > > > > Nearly all the code that is generated works very well, but there is just > one type of definition in the schema that Castor seems to have a bit of > trouble with. > > > > I have a type that is defined as follows: > > > > <xs:complexType name="ON" mixed="true"> > > <xs:annotation> > > <xs:documentation> > > A name for an organization. A > sequence of name parts. > > </xs:documentation> > > </xs:annotation> > > <xs:complexContent mixed="true"> > > <xs:restriction base="EN"> > > <xs:sequence> > > <xs:choice > minOccurs="0" maxOccurs="unbounded"> > > > <xs:element name="delimiter"> > > > > <xs:complexType mixed="true"> > > > > <xs:complexContent mixed="true"> > > > > <xs:restriction base="en.del"> > > > > <xs:attribute name="partType" type="cs_OrganizationNamePartType" > fixed="DEL"/> <!—This partType “overrides” the > partType in en.del with a new type cs_OrganizationNamePartType à > > > > </xs:restriction> > > > > </xs:complexContent> > > > > </xs:complexType> > > > </xs:element> > > … <!—snip à > > </xs:complexType> > > > > Note that the above element named “delimiter” is a restriction of a type > named “en.del”. This type is defined as follows: > > > > <xs:complexType name="en.del" mixed="true"> > > <xs:complexContent mixed="true"> > > <xs:restriction base="ENXP"> > > <xs:attribute > name="partType" type="cs_EntityNamePartType" fixed="DEL"/> > <!—cs_EntityNamePartType is the type specified for this attribute here à > > </xs:restriction> > > </xs:complexContent> > > </xs:complexType> > > > > Notice that attribute “partType” is defined in the “en.del” complexType > and also “re-defined” in “delimiter” element in the complex type “ON”. I > say re-defined because the type of the attribute named “partType” is > “cs_EntityNamePartType” in the “en.del” complex type, whereas it is of > type “cs_OrganizationNamePartType” in the “delimiter” attribute in the > complex type named “ON”. > > > > I’m sure you can already tell that this is quite “suspicious”! > > > > When I try to generate code for the ON complex type, there is something > like this that is the output: > > > > *public* *class* ONDelimiter *extends* castor.test.En_del > > *implements* java.io.Serializable > > { > > > > > > //----------------/ > > //- Constructors -/ > > //----------------/ > > > > *public* ONDelimiter() { > > *super*(); > > > setPartType(castor.test.types.Cs_OrganizationNamePartType./valueOf/("DEL")); > > ///ERROR!!!! > > setContent(""); > > } > > > > … <snip> > > > > Now, the En_del class is generated with a method of the following signature: > > > > /** > > * Field _partType. > > */ > > *private* castor.test.types.Cs_EntityNamePartType _partType = > castor.test.types.Cs_EntityNamePartType./valueOf/("DEL"); > > > > > > //----------------/ > > //- Constructors -/ > > //----------------/ > > > > *public* En_del() { > > *super*(); > > > setPartType(castor.test.types.Cs_EntityNamePartType./valueOf/("DEL")); > > setContent(""); > > } > > > > > > //-----------/ > > //- Methods -/ > > //-----------/ > > > > <snip!> > > > > /** > > * Returns the value of field 'partType'. > > * > > * [EMAIL PROTECTED] the value of field 'PartType'. > > */ > > *public* castor.test.types.Cs_EntityNamePartType getPartType( > > ) { > > *return* *this*._partType; > > } > > > > <snip!> > > > > /** > > * Sets the value of field 'partType'. > > * > > * [EMAIL PROTECTED] partType the value of field 'partType'. > > */ > > *public* *void* setPartType( > > *final* castor.test.types.Cs_EntityNamePartType partType) { > > *this*._partType = partType; > > } > > > > <snip!> > > > > Of course the ONDelimiter class extends from the En_del class. The > En_del class has a field named _partType that is of type > castor.test.types.Cs_EntityNamePartType. Because ONDelimiter subclasses > En_del, it can’t set _partType to a > castor.test.types.Cs_OrganizationNamePartType instance like it attempts > to in the ONDelimiter constructor. And the ONDelimiter class has no > field of that type either. > > > > If it helps, here are the definition of Cs_EntityNamePartType and > Cs_OrganizationNamePartType snippets of the schema: > > > > <xs:simpleType name="cs_EntityNamePartType"> > > <xs:restriction base="cs"> > > <xs:enumeration value="FAM"/> > > <xs:enumeration value="GIV"/> > > <xs:enumeration value="PFX"/> > > <xs:enumeration value="SFX"/> > > <xs:enumeration value="DEL"/> > > </xs:restriction> > > </xs:simpleType> > > > > <xs:simpleType name="cs_OrganizationNamePartType"> > > <xs:restriction base="cs_EntityNamePartType"> > > <xs:enumeration value="PFX"/> > > <xs:enumeration value="SFX"/> > > <xs:enumeration value="DEL"/> > > </xs:restriction> > > </xs:simpleType> > > > > > > > > I’m hoping that you might be able to help me with either a workaround > (changing the code directly is ok with me because this is the only type > of error in the Castor-generated code). I say “type” of error because > this schema has this kind of definition a number of places and the > errors are all similar. Of course, if there is a modification to the > binding file that I can make for either of these types then that is > better! One idea might be to not have one type extend from another, and > just have all the classes separate concrete classes. Is that a > possibility in Castor? > > > > Thank you in advance for taking some time with this matter. I appreciate > any feedback and/or help you can give me. > > > > ---------------------------------------------- > > Justin Permar > > Research Programmer > > Department of Biomedical Informatics > > The Ohio State University > > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
