What I would do is put the version in the namespace associated with your schema, and also include the version in the source-generation by changing the default package. This way, you can support older version of the XML schema and java packages by references the old version.
The serialVersionUID isn't as helpful since a) it doesn't apply to the XML side, and b) objects from and older version are unusable in the new version, which may not be the best situation. (Depening on your business requirements, of course.) The trick is to get your software that works with your new schema version to reconigze the older version and deal with it in a 'compatiability' mode. On Wed, 2001-12-05 at 11:19, Robert Ollila wrote: > Hi all, > > There is a significant issue that we are concerned with here regarding the > XML instances that are ultimately created from the marshalling framework and > I have not seen it discussed on this list. The issue is version control. > > For example if I start with SchemaA.xsd and generate java objects from it, I > can now create and store XML instances in files. But what happens when I > deploy this version and months later I extend SchemA.xsd by creating > SchemaB.xsd. Let's assume that SchemaB just adds some fields to the > existing java classes. Now what happens when I try to marshall an older XML > instance with classes generated from SchemaB? > > A similar issue concerns serialization. The java serialization mechanism > will not allow you to serialize older persistant objects with newer versions > of the same class. One way to evercome this is to set a varialble in the > class as follows: > > protected static final long serialVersionUID = <some number>; > > This static variable would be the same across old and new classes generated > by Castor. So, the question is, how can we set a static variable like this > in generated code. > > I have been a proponent of using Castor in many ways with my development > team, but this issue is the main obstacle that keep my other team members > from adopting Castor. > > Has anyone implemented frameworks to handle version issues like these? Any > help would be appreciated. > > Bob. > > ====================================== > Robert Ollila > Software Engineer > Vina Technologies > 25 Manchester Street > Merrimack, NH 03054 > 603-589-0669 > ====================================== > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev -- Virtually, Ned Wolpert <[EMAIL PROTECTED]> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
msg03344/pgp00000.pgp
Description: PGP signature
