IMHO, this is a difficult problem. It would be nice to change only those structures that change. The problem with that is, though, that a parent class needs to know whether to load the old child or the new one. So, one is inclined to also change the parent. This behaviour bubbles all the way up to the root. Be sure to share with the group whatever solution you land on. To avoid this problem, I think it will require more customization than plain SoureGenerator-generated code allows. --Erik
-----Original Message-----
From: Bender Heri [mailto:[EMAIL PROTECTED]
Sent: Mon 11/17/2003 7:52 AM
To: [EMAIL PROTECTED]
Cc:
Subject: [castor-dev] Different Spec versions
Hi
My server application which receives XML-Messages must treat 2 different
specification versions of the XML-File. Most of the types, attributes and
elements stay the same between the versions (98%) but some are different
(mandatory/optional, existing/not existing, renamed elements).
I thought of resolving this problem like this:
- having 2 different schemas which include a third schema where the
unchanged items are declared
- let castor build the classes in two different subpackages
- creating wrapper classes for each castor generated class which implements
an interface
- working only with the interface
The problem is now, that there are really a lot of elements and types. I
have to create for each castor generated class one interface and two
wrappers (one for each version. Maybe I must support three or even more
versions in future) -> much boring error-prone work.
Is there annother way of addressing such an issue? I particular the common
unchanged types and elements should be wrapped into the same class (not
different classes with the same name in different sub packages).
Heri
BTW: Castor 9.5.2, java 1.4.2
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
<<winmail.dat>>
