RE: AXIS and optional changes to request / response message type definition

[chris]

Title: july4.html

When Axis encounters a SOAP element that does not conform to a corresponding Java object or attribute, a deserialization error is thrown.   If the consumer or service *USES* the optional element, then the message exchange will fail.  Beans must be regenerated if you desire to serialize/deserialize the new elements using the Axis serialization framework.   Alternatively, document based messaging can be used, but then the custom parsing code must determine how to handle the occurrence of an unknown element (throw an exception or drop the data).   The OSGA specification has good practical advice on Web Service versioning from a WSDL perspective…  The infrastructure vendors are starting to tackle the issue so that deployments don’t degrade into ‘Web Service Hell’   /Chris   -----Original Message----- From: Manchaiah, Girish (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 10:54 AM To: '[EMAIL PROTECTED]' Subject: RE: AXIS and optional changes to request / response message type definition   Does that mean AXIS beans do not support optional changes to request/response message definition. Meaning any optional change to request/response message definition will result in deserialization error. -----Original Message----- From: Manchaiah, Girish (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 2:27 PM To: '[EMAIL PROTECTED]' Subject: AXIS and optional changes to request / response message type defi nition Do I need to regenerate beans (generated using AXIS wsdl2java) wheneverOPTIONAL changes are made to request / response message? Even when the client/service don't have to pickup changes as and when theresponse/request message definition changes.   regards, girish