Hello Lawrence, thank you very much for your help. It helped me understand the basic concept - why you are using XmlLong and the other classes. But what I didn't really understand is why you don't use java.lang.Long for convenience, but the primitive type long.
My Problem is the following: I am working with ibatis (ORM-Tool). For this tool I write xml-mapping files, so called sql-maps, where I specify a class with its properties. So when I query my Database, ibatis looks at this mapping file and then searches for the specified class. When it found the class it creates an instance and fills in the propertys with the help of the getter and setter methods. The problem is that the ORM-Tools work with the Wrapper classes because there a null is possible. If for example a database identifier has null as its value, the ORM-Tool knows that it still has to save this Object to the database, if the value is not null, but for example 0, then the ORM-Tool thinks that the Object is already persistent. Because there are so many classes we just need once, we want to have them generated from XmlBeans. Because of this Problem, neither the primitive type nor the Xml... classes work for us. To solve this problem for us, I have changed the source code a bit, but that isn't a really code solution because with each new release from XmlBeans, we have to adjust the code again. A nice solution for this specific problem we found with JAXB. There you can specify user definded type within annotations. Is there a plan to implement this feature in XmlBeans? Or is there anything that speaks against it? If there is nothing that speaks against it, I would like to implement the JAXB Standard of specifying user defined types in XmlBeans, but for doing that I need help. I hope I could clearly state my problem and you can help me. Greetings, Ramona -----Ursprüngliche Nachricht----- Von: Lawrence Jones [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 6. April 2006 20:25 An: dev@xmlbeans.apache.org; [EMAIL PROTECTED] Betreff: RE: Wrapper classes instead of primitive types in the Generated classes Hi Ramona I don't think there is any way to produce getters and setters that take/return java.lang.Long instead of long within XmlBeans. However for all getters / setters which use a fundamental type (such as long) you also automatically get xgetXXX() and xsetXXX() methods which will take/return an org.apache.xmlbeans.XmlLong (see http://davidbau.com/archives/2003/11/14/the_design_of_xmlbeans_part_1.ht ml for an explanation of why using e.g. java.lang.Long would cause problems with type correspondence within XmlBeans). Depending on what you want to do this may help. Cheers, Lawrence > -----Original Message----- > From: Ramona Krickan [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 06, 2006 10:22 AM > To: [EMAIL PROTECTED] > Subject: Wrapper classes instead of primitive types in the Generated > classes > > Hello, > > I have a problem with the resulting Java Interfaces from the XML Schema > File. > xsd:long maps to the Java primitive Type long and not to the Java Wrapper > class Long. Is it possible to change that or is it planned to change that? > In JAXB you can specify a javaType you want to have with the help of > Annotations: > <xsd:annotation> > <xsd:appinfo> > <jxb:javaType name="java.lang.Integer"/> > </xsd:appinfo> > </xsd:annotation> > Is there a way of doing this with XmlBeans? > > Thanks in advance for any help. > > Ramona > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
