Ok, thanks.

I added a bug to JIRA on the subject.

Regards,
David Currie

Adrian Dick wrote:



This is an error in the generated server-side skeletons.

The name of the return message should be taken from that specified in the
WSDL, as we see for the client stubs
     minfo.getOutputMessage().getLocalPart()
Using the method name and appending "Response", as is done for the server
skeletons, is wrong.

I can see how it's easy to get confused, as most example WSDLs do use the
convention of the messages being called <method name>Request and <method
name>Response.
The WSDL2Ws tool needs to be updated so that both Client and Server use the
OutputMessage name.

Regards,
Adrian
_______________________________________
Adrian Dick ([EMAIL PROTECTED])


David Currie <[EMAIL PROTECTED]> wrote on 14/01/2005 01:02:48:



Hi.

I've been having some problems with a web service whose code skeleton I
generated using the wsdl2ws tool available in Axis.  Using C++ as the
target language, I started having problems with receiving messages in
(generated) clients, also in C++.

After breaking out GDB and Ethereal, I discovered that the XML fields
generated by the server are not exactly compatible with the fields
expected by the client.  The problem is in the name of the Response
message.  While the generated client expects the message name to be the
one declared in the WSDL ( minfo.getOutputMessage().getLocalPart() on
line 475 of file ClientStubWriter.java), the generated server creates a
message name using the method name with the string "Response" appended
to the end (minfo.getMethodname()+ "Response"(...) on lines 292-293 of
file WrapWriter.java).

Is there a reason for this that escapes me?  When I use a wsdl file that
declares the return message as being called something other than
<methodname>Response, the client doesn't work, and simply exits with the
message "aborted".  If I change the server-side generator to use the
same name as the client-side for the return message, replacing the
second string mentioned above with the first one, then the client and
server work together flawlessly.

Is this a bug, or am I missing something?

David Currie








Reply via email to