When do return parts have elements?

[Benson Margulies <bi...@gmail.com>]

Dan,

Until a few minutes ago, I had everything working by following the
following rule: in RPC, return values have an element based on the
output part. In Doc/Literal, there is no such element.

Then I hit a counter-example from one of our demos. The CXF service for
this method produces a part-level element. And I'm failing to figure out
from the model data structure how I'm supposed to tell that this needs
different treatment. My first thought was that isElement on the part
would clue me in. No such luck. Many of the output message parts which
do not generate a part-level element have isElement = true.

 @ResponseWrapper(localName = "sayHiResponse", targetNamespace =
"http://apache.org/hello_world_soap_http/types", className =
"org.apache.hello_world_soap_http.types.SayHiResponse")
    @RequestWrapper(localName = "sayHi", targetNamespace =
"http://apache.org/hello_world_soap_http/types", className =
"org.apache.hello_world_soap_http.types.SayHi")
    @WebResult(name = "responseType", targetNamespace =
"http://apache.org/hello_world_soap_http/types")
    @WebMethod
    public java.lang.String sayHi();

Re: When do return parts have elements?

[Benson Margulies <bi...@gmail.com>]

On Wed, 2007-12-12 at 22:41 -0500, Daniel Kulp wrote:
> 
> I'm not sure I understand the question/issue. 

This turned out to be an issue with the sadly baroque code I've written
for code-gen for response parsing.

In the 'bare' case, to make the code look for the write XML element, I
ended up writing some code that looks for the profile
part->element->anonyoustype->namedElement, and uses the named element.

That code was going off in a wrapped case.

Almost certainly, this monkey-puzzle could be replaced by less exotic
stuff that doesn't know if it is dealing with 'wrapped' or not, but,
then again, this might run into the elements that aren't in the schema
that we discussed recently.




>  
> 
> For wrapped doc/lit:
> The @ResponseWrapper annotation defines the wrapper element name.
> The @WebResult defines the name of the element in the wrapper sequence 
> that represents the return type.
> 
> For doc/lit/bare:
> @WebResult is the element name and part name for the entire response
> 
> For RPC:
> @WebResult defines the part name.   The part is a "type", not an element.
> 
> Dan
> 
> 
> On Wednesday 12 December 2007, Benson Margulies wrote:
> > Dan,
> >
> > Until a few minutes ago, I had everything working by following the
> > following rule: in RPC, return values have an element based on the
> > output part. In Doc/Literal, there is no such element.
> >
> > Then I hit a counter-example from one of our demos. The CXF service
> > for this method produces a part-level element. And I'm failing to
> > figure out from the model data structure how I'm supposed to tell that
> > this needs different treatment. My first thought was that isElement on
> > the part would clue me in. No such luck. Many of the output message
> > parts which do not generate a part-level element have isElement =
> > true.
> >
> >  @ResponseWrapper(localName = "sayHiResponse", targetNamespace =
> > "http://apache.org/hello_world_soap_http/types", className =
> > "org.apache.hello_world_soap_http.types.SayHiResponse")
> >     @RequestWrapper(localName = "sayHi", targetNamespace =
> > "http://apache.org/hello_world_soap_http/types", className =
> > "org.apache.hello_world_soap_http.types.SayHi")
> >     @WebResult(name = "responseType", targetNamespace =
> > "http://apache.org/hello_world_soap_http/types")
> >     @WebMethod
> >     public java.lang.String sayHi();
> 
> 
> 

Re: When do return parts have elements?

[Daniel Kulp <dk...@apache.org>]

I'm not sure I understand the question/issue.  

For wrapped doc/lit:
The @ResponseWrapper annotation defines the wrapper element name.
The @WebResult defines the name of the element in the wrapper sequence 
that represents the return type.

For doc/lit/bare:
@WebResult is the element name and part name for the entire response

For RPC:
@WebResult defines the part name.   The part is a "type", not an element.

Dan


On Wednesday 12 December 2007, Benson Margulies wrote:
> Dan,
>
> Until a few minutes ago, I had everything working by following the
> following rule: in RPC, return values have an element based on the
> output part. In Doc/Literal, there is no such element.
>
> Then I hit a counter-example from one of our demos. The CXF service
> for this method produces a part-level element. And I'm failing to
> figure out from the model data structure how I'm supposed to tell that
> this needs different treatment. My first thought was that isElement on
> the part would clue me in. No such luck. Many of the output message
> parts which do not generate a part-level element have isElement =
> true.
>
>  @ResponseWrapper(localName = "sayHiResponse", targetNamespace =
> "http://apache.org/hello_world_soap_http/types", className =
> "org.apache.hello_world_soap_http.types.SayHiResponse")
>     @RequestWrapper(localName = "sayHi", targetNamespace =
> "http://apache.org/hello_world_soap_http/types", className =
> "org.apache.hello_world_soap_http.types.SayHi")
>     @WebResult(name = "responseType", targetNamespace =
> "http://apache.org/hello_world_soap_http/types")
>     @WebMethod
>     public java.lang.String sayHi();



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog