Hi John, "Weir, John" wrote: > > Without having to write a test case for this - does anyone know what the > down sides of this approach are? I don't believe it's complete. Some code will probably need to be written to either handle or ignore child elements and text. > > It seems such a good feature :-). Being able to bind a valid XML document, > but being able to ignore non mandatory elements i.e. optional or choice > items We've thought about this in the past, and we actually added it for attributes and at some point we'll probably add it for elements too... However, if the Schema changes by only adding optional elements as you suggest, why not simply regenerate the source code with the same version of Castor that was used to generate the code from the initial schema? > > If so - why don't we make this a runtime property ? > It's reasonable to do so, just a matter of someone actually doing it and testing it. --Keith > -----Original Message----- > From: Sean McCauliff [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 19, 2002 7:32 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Help - can we handle new schemeas with Java > classesgenerated fro m old schemas? > > Yes versioning is important and it would seem XML would be the way to > go, however Castor does not seem to support this very well. If you > don't mind changing the source code for Castor then I think the > following modifications to UnmarshalHandler.java I assume this is safe > since it looks like there a conditions under which the existing code > will just pass over fields that it can not map into a Java class. > > Good luck, > -Sean > > //the field descriptor is still null, we face a problem > if (descriptor == null) { > String msg = "unable to find FieldDescriptor for '" + name; > msg += "' in ClassDescriptor of " + classDesc.getXMLName(); > //if we have no field descriptor and > //the class descriptor was introspected > //just log it > if (Introspector.introspected(classDesc)) { > message(msg); > return; > } > > //CHANGE > if (true) return; > //CHANGE > > //but if we could not find the field descriptor > //whereas a class descriptor has been provided (using the > //Source Generator for instance) > else throw new SAXException(msg); > > } > > Sonnathi, Venkat Ramana wrote: > > >Hi, > > > >We are trying to see if we can handle marshalling/unmarshalling of XML > >documents which contains a few extra elements (New schema) with the Java > >classes generated by Castor using old schema. Basically we want to ignore > >the new elements. This is very crucial as we have a number of clients > >talking to middleware and we don't want to regenerate classes and > re-compile > >all the clients which don't require the newly added fields in the response. > > > >TIA, > >--Venkat. > > > >----------------------------------------------------------- > >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 > > ----------------------------------------------------------- > 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
