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
