You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Dennis Sosnoski <dm...@sosnoski.com> on 2006/05/07 02:57:20 UTC

[Axis2] Handling of empty requests or responses (Was: Re: svn commit: r400185...)

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