Ben, Perhaps this is too simplistic for your needs, but for mine I simply have my generated classes extend a class that implements the timestamp methods. I don't have a need to persist the timestamps, so this works for me, unfortunately that may not be the case for you...
Good luck - Margaret -----Original Message----- From: Ben Cox [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 6:10 PM To: [EMAIL PROTECTED] Subject: [castor-dev] jdoGet/SetTimeStamp We have been working toward using both the JDO and XML functionality of Castor on the same objects, and in particular toward either generation of the JDO mapping file (from the same XML Schema and/or the marshallable/unmarshallable source files after running the Source Generator), or inclusion of JDO-specific elements in the ojects that are generated from our schema. Currently, our approach is to create the JDO mapping file. One really surprising barrier to our implementation, which requires the use of long transactions, is the names of the jdoGetTimeStamp() and jdoSetTimeStamp() methods in the TimeStampable interface. I'm probably missing something, but there's no good reason I can see to step away from the Bean-like naming conventions of getXXX and setXXX! For what we're doing, that little decision seems to create a pretty big snag. It would be a simple matter to have the XML/JDO objects implement an interface with getJDOTimeStamp() and setJDOTimeStamp() methods, instead, because one could then simply include an attribute called JDOTimeStamp in the schema definition. This would result in the generated marshallable/unmarshallable objects, themselves, implementing those methods correctly without having to be hand-edited to add that field (god forbid!). If the method names don't start with get/set, I haven't seen any simple way to coerce the SourceGenerator to create them from the schema, so it looks like we may have to hand-edit after all! A grep in /src/ shows that these methods of the TimeStampable interface are only ever called by org.exolab.castor.persist.ClassMolder, (and about five of the test classes), so perhaps it would not be a big deal to change these method names? Or, for backward compatibility, provide this interface separately and rewrite the four calls to add a check and cast (to TimeStampable or, say, TimeStampBeanable) before checking or setting a timestamp. I'd rather not have to mangle my own copy of Castor to make this work, becuase that's not exactly a maintainable approach, but it might prove better than editing all that generated code! Is it likely that this is going to be cleared up in a future release? Or, is there a compelling reason I'm failing to see not to use bean-like method names? Has anyone else faced this problem yet, and perhaps know another (maintainable) way to get around this? Thanks for any advice, Ben Cox && Tim Ruppert ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
