Werner, I have added an attachment following the proper guidelines. Sorry for providing an incorrect attachment earlier.
---------------------------------------------- Justin Permar Research Programmer Department of Biomedical Informatics The Ohio State University Phone: 614-292-9845 Fax: 614-688-6600 [EMAIL PROTECTED] > -----Original Message----- > From: Werner Guttmann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 22, 2007 4:04 PM > To: [email protected] > Subject: Re: [castor-user] code generation: schema type restriction > "re-defines" the type of an attribute from the base type > > 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/("DE > L")); > > ///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 --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
