How about having the client use XSL to transform any messages into the original client structure and thus "weeding out" any extra fields? The XSL transformation would be done prior to unmarshalling the message. In a recent thread Keith Visco and Ned Wolpert indicated that it might be worthwhile to implement more direct support for this type of thing in the Caster framework. Keith, has there been any more investigation on this?
Bob. -----Original Message----- From: Panduranga M. Prabhu [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 8:06 AM To: [EMAIL PROTECTED] Subject: [castor-dev] Castor support for additional nodes in XML All. We are using Castor in a large Enterprise Application Integration project. We are using Castor to marshall/unmarshall XML messages to talk to different Enterprise Applications through a Message Broker. Everything was going fine until we stumbled upon this problem. -- we generate classes from the XSDs for XML Messages given by systems that service many clients -- Along the way, some System adds some additional nodes to the XML Messages for particular client/s. The structure/names of earlier nodes reamin un-altered. -- These changes ideally should not affect us, as we as a client do not care about these new additional nodes. However as we are using Castor, the generated classes throw Exception while unmarshalling and only way is to regenerate the classes for new XSDs. This is a big problem for us, as we need to regenerate the classes, bring down our application deploy and start application again. Anybody has suggestions on how to avoid this code generation ? Any inputs highly appreciated. thanks - prabhu ----------------------------------------------------------- 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
