Sanjiva Weerawarana wrote:
On Sat, 2006-05-06 at 15:25 +1200, Dennis Sosnoski wrote:
Hi Sanjiva,
This change was actually for the client stub, so my comment was somewhat
off - the case it's handling is when the request has no data,
corresponding to a method call with no parameters. The child element of
the SOAP:Body is still needed in order to identify the operation.
Not necessarily .. it could be done using wsa:Action or other means. It
again depends on what the WSDL says!
True, it can be handled that way. Unfortunately I don't think this
information (whether there's an element or not) is passed to the code
generation XSLT currently, as mentioned below. In any case, the prior
code generation threw an NPE regardless of what the WSDL said, so I
think this has to be an improvement. :-)
I did look into the related issue of a void response, and how that's
handled by the message receiver. As you said, depending on how that's
represented in the WSDL and service definition this could be handled in
two ways: As an INOnly operation, in which case there should not be any
child element in the SOAP:Body; or as an INOUT operation, in which case
the response will normally have a child element in the SOAP:Body (or at
least *can* have a child element in the SOAP:Body, if the corresponding
message has a part defined). The message receiver is currently not
handling that second case correctly - it generates an empty SOAP:Body -
but this is a less serious issue since Axis2 and many other frameworks
will ignore the response anyway. It'd take a more substantial change to
fix this problem, since the code generator doesn't appear to be passing
the element information into the XSLTs.
I'm confused- the message receiver must be a generated message receiver
to handle this kind of stuff. In that case, it must have the right
behavior per the WSDL or I'd consider it a bug.
Yes, it's a bug in the current message receiver generation.
My apologies if I'm being thick.
Not at all, this is a confusing area with all the many options to handle
and I'm glad we can work through the alternatives. It looks to me like
we're going to need to add more information to the XML passed to the
code generation XSLTs in order to handle all the possible cases
properly. I'm looking at extending it anyway for wrapped handling, so
should be able to handle this at the same time.
Moving this over to axis-dev where more people can be aware of the
discussion. For those who didn't see the start of the thread, it grew
out of a commit I'd made for the InterfaceImplementationTemplate.xsl. My
comment said the commit was to handle empty responses, but it was
actually to handle empty requests.
- Dennis
