For posterity I'll post my solution :-)
I solved this by creating a custom BeanSerializer. I just used the Apache
BeanSerializer and ignored the exception thrown by the getWriteMethod in
the unmarshall method:
try {
propWriteMethod = getWriteMethod(param.getName(), properties,
javaType);
} catch (IllegalArgumentException iae) {
System.out.println("Warning, IllegalArgumentException thrown, but
continuing");
System.out.println( iae );
}
I only did this on the web service side (in my case I don't forsee the
service upgrading before the client, the service will always be behind).
So I created the new class in a new package
(com.jpmc.ibportal.integration.soap.encoding.soapenc.ForgivingBeanSerializer)
and modified the DeploymentDescriptor.xml to reflect the serializer to use
for my beans, e.g.
<isd:map ... xml2JavaClassName=
"com.jpmc.ibportal.integration.soap.encoding.soapenc.ForgivingBeanSerializer"
java2XMLClassName="org.apache.soap.encoding.soapenc.BeanSerializer"/>
I only changed the serializer for the deserializer (xml2JavaClassName).
GLUE was recommended but at this stage I did not want to make a drastic
change...
Shawn.
hughes_shawn@jpm To: [EMAIL PROTECTED]
organ.com cc:
Subject: Change management of web
service input/output models???
03/11/2002 04:48
PM
Please respond
to soap-user
What is the best way to deal with changes in the input and/or output model
of a web service?
Any references to general change management solutions are appreciated.
In my case, there are n different groups implementing a SOAP service. If a
new field is added to the input model all groups must simultaneously
upgrade the input model definition (otherwise deserialization will fail
once the model is changed in the client). Generally, however, the change
will simply be the addition of a new field, not modifying or removing an
existing field. Given this, a good solution is to allow legacy services to
simply ignore the new field. This will allow the interested service
implementor to recognize the new field while the other groups ignore it
until they are ready to upgrade the input model.
One solution is to subclass or create my own BeanSerializer which drops a
field it doesn't recognize during deserialization (currently the Apache
BeanSerializer will fail). I thought this was a good idea until I tried to
find someone else who has done the same thing. I couldn't, which makes me
think this may not be a good idea.
Another is to flatten the input model to a Map such that all input models
are just name/value pairs. I don't like this because the input model must
be flattened.
Lastly, I could add a new service accepting the new input model. This
would require UDDI wrapper code in the client to direct the request to the
appropriate version of the service.
Any experiences or suggestions welcome.
Thanks,
Shawn.
This communication is for informational purposes only. It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made
herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
