See the earlier thread (attached) on this issue. I haven't had the
opportunity to try -Eosv with Axis2 1.3 yet. I'm curious, are you using
Axis 1.3 or an earlier version?
As I explained in my earlier post, the only way I have been able to work
around this issue is to modify the XSLT contained in the
axis2-adb-codegen jar file to cause different client code to be emitted.
Basically you need the generated client code to silently consume the
unexpected elements / subelements as it is pull-parsing responses,
instead of throwing an exception.
-----Original Message-----
From: Leon Hwang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 29, 2007 2:33 PM
To: [EMAIL PROTECTED]; [email protected]
Subject: [Axis2] Axis2 and New field
Greetings,
I am writing a server that returns an object, say User object,
containing only username.
I create a client using its wsdl (with option -d adb -uw -Eosv).
The client is able to retrieve username field correctly.
Later I added one more field to User object, say password, and
redeployed it to the server.
Now the client complains about the field with "unexpected subelement
password". (ADBException)
This will happen a lot in business world as their spec changes.
Is there some way (either in client or server) we can make it ignore
extra elements?
Thanks in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- Begin Message ---
Axis2 adb style clients can be made tolerant of new elements added to a web
service by modifying ADBBeanTemplate.xsl contained in axis2-adb-codegen-1.2.jar.
This xsl is used to generate the Java code which pull-parses responses from the
web service. This generated code is what throws exceptions when it encounters
unrecognized elements. It is fairly trivial to modify the xsl to generate code
which is tolerant of newly-added elements (i.e. just silently consumes and
discards them) instead of crashing. I have done this. To some no doubt this is
heresy, to others (myself included) it is worthwhile because it can be used to
achieve looser coupling between the client and service, and that is good. There
are many business use cases where a service is extended with some new elements
which are not needed by existing clients. The notion that every previously
deployed client should have to be recompiled and redeployed just because the
service was extended is broken, IMHO.
_____
From: Lahiru Sandakith [mailto:[EMAIL PROTECTED]
Sent: Friday, August 03, 2007 4:13 AM
To: [email protected]
Subject: Re: Newbie question about using axis as webservice client
Hi DelGurth,
As you say the webservice changed then the wsdl also should be different, so
IMO there is no option other than regenerating the client using wsdl2java tool
(via Eclipse), because its an interface level change.
Thanks
Lahiru Sandakith
On 8/3/07, DelGurth <[EMAIL PROTECTED]> wrote:
Hi,
I recently stated using axis as my web service client. I've used the
wsdl2java tool (via Eclipse) to generate the client code based on the
wsdl file of the service.
Now the web service changed, it contains a new field, and my client
application doesn't work anymore. Is there a way to make my client
ignore fields that are unknown to it?
I tried finding an answer in the client-side axis documentation, but I
can't find it, unfortunately. That's why I end up here.
Regards,
Wessel van Norel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thanks
Lahiru Sandakith
http://sandakith.wordpress.com/
GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
