Hi David, Thanks for this input, sounds like a clear bug to me.
Can you please raise it on the Castor JIRA site and I'll take a look for you. http://jira.codehaus.org/browse/CASTOR Cheers, Andy. -----Original Message----- From: David Easley [mailto:[EMAIL PROTECTED] Sent: 04 August 2005 20:41 To: [email protected] Subject: [castor-user] Castor XML bug (+suggested fix, +new feature request) Problem description =================== This relates to Castor 0.9.7 When using a binding file to specify that certain primitive fields should be wrapped (rather than using the Castor properties file to specify that ALL primitives should be wrapped) the 'descriptor' class will still contain a call to the field's delete method and therefore won't compile because there won't be such a delete method in the actual binding class ('has' and 'delete' methods are omitted when primitive wrapper classes are used). Example: In the following example the FooDto type has a barId field that references a BarDto by id. A Foo doesn't always have an associated Bar, so the barId element is defined as minOccurs="0" in the XSD. Snippet from XSD: <xs:complexType name="FooDto"> <xs:sequence> <xs:element name="id" type="xs:int"/> <xs:element name="name" type="xs:string"/> <xs:element name="barId" type="xs:int" minOccurs="0"/> </xs:sequence> </xs:complexType> Snippet from the binding file that causes the problem: <complexTypeBinding name="FooDto"> <java-class name="FooDto"/> <elementBinding name="barId"> <member wrapper="true"/> </elementBinding> </complexTypeBinding> Suggested Fix ------------- Line 519 in org\exolab\castor\builder\DescriptorSourceFactory.java: if (xsType.isPrimitive() && !_config.usePrimitiveWrapper()) { Should be: if (xsType.getJType().isPrimitive() && !_config.usePrimitiveWrapper()) { I suspect this could now be simplified to: if (xsType.getJType().isPrimitive()) { I've tested this and it works OK for my XSD and binding file. (Should XSType.isPrimitive() be deprecated in favour of XSType.getJType().isPrimitive()?) Castor feature suggestion ========================= In our project we actually want DTO code generated as follows: For primitive properties (int, long, etc.) we would like the getters and setters to use the equivalent wrapper class (Integer, Long, etc.) if minoccurs="0" and maxoccurs="1" in the XSD. If minoccurs="1" and maxoccurs="1" then the getters & setters should use the fundamental data type. Where used consistently within a particular project/API, this style provides a useful strong cue to anyone reading the code. If a getter returns an int, you know that a value will always be provided. If on the other hand it returns an Integer, you infer that it could return null. Currently (0.9.7), to achive this we have to use the binding file to specify that certain member fields should be wrapped. This tedious and error prone as the binding file has to be kept in sync with the 'minoccurs' attributes in the XSD file. In addition to fixing the bug described above, Castor would benefit from an option (preferably command line) to support this style of coding. David Easley ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- CODA has a new world-class consolidation package. Find out more about www.coda.com/ocra <http://www.coda.com/ocra> The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
