Em Quinta 16 Fevereiro 2006 14:29, o Andreas Bohnert escreveu: > thanks a lot for your answer, robert! > > > This question comes up a lot recently. First, AFAIK you won't see the > > axis 1.x deserialization errors in axis2. As far as not syncing changes, > > I myself haven't found a compelling reason to not sync changes and so I > > haven't tried it. However, what you could do is trying to define your new > > elements as: > > > > element minOccurs="0" maxOccurs="1" > > I'm not sure what you mean with 'sync changes'.Is there a technique to > automatically sync wsdl changes to the webservice client? > Am I'm doing something wrong? > my situation is this: > > the webservice client asks for data and the service is returning an > array of complex data objects. the client displays the data or whatever. > > I give the client to different customers. some of them will use the > client, some of them will build their own solution based on my example > client. > now, if I have to change my webservice ( add fields to my complex data > object) our customers will be notified. some of them will update their > client, but some of them wont. > And I want to satisfy both with one webservice. > when I use wsdl2java generator to build up the client, a java bean is > generated for each complex type, so this beans (the old and the one > after the update) do not match after a change and that's why I was > asking for deserialization errors.
That's what I meant by syncing changes - manually create new classes via wsdl2java on the new wsdl, on both the client and server sides, ie, asking the client to use a new jar or class based on the new wsdl. You could try minOccurs = 0 on any new fields, and my guess is that since the service doesn't require them to be part of then envelope, they won't be missed if they are not there. IOW, they can't be mandatory fields. > > > You can implement handlers to access the bodies and access all the > > elements, but I don't see how it solves your problem. If you have fewer > > fields arriving from the client because it hasn't been synced, how does > > modifying the body help you? Maybe I misunderstand the question. > > I don't want to modify the body. I just want to read the content on the > client side. > If I write the client in such a way, that it parse the returned soap > body (the returned array of data objects), in this case, I don't depend > on a static bean. this will still work after an update (adding fields) > to the service. Sure its not easier to just ask your clients to upgrade? I do it often enough and no one complains really. IOW, Embrace change. Try thinking of ways to make the upgrade easier if need be. Otherwise, sounds you need a client side handler and then convert the soap body to Document , use Element.appendChild() or something, and then convert back to soap message. > > please correct me, if I have someting wrong on my mind. > thanks again, andreas HTH, Robert http://www.braziloutsource.com/
