You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by David Robertson <dw...@lbl.gov> on 2009/05/11 23:19:06 UTC
code generation problem
I'm having a problem with the attached WSDL. It is valid, but the code
generated for the operation has the output elements, unwrapped, in the
parameter list and a void return type. I don't have the option of
changing the WSDL. Is this something that can be fixed with enough
binding entries, or would the problem be manifesting before it gets to
the binding.
-David Robertson
Re: code generation problem
Posted by Daniel Kulp <da...@kulp.com>.
On Thu May 14 2009 2:07:12 pm David Robertson wrote:
> Daniel Kulp wrote:
> > On Mon May 11 2009 5:19:06 pm David Robertson wrote:
> >> I'm having a problem with the attached WSDL. It is valid, but the code
> >> generated for the operation has the output elements, unwrapped, in the
> >> parameter list and a void return type. I don't have the option of
> >> changing the WSDL. Is this something that can be fixed with enough
> >> binding entries, or would the problem be manifesting before it gets to
> >> the binding.
> >>
> >> -David Robertson
> >
> > This code is generating exactly per spec.
> >
> > You could switch it to "bare" mode with a binding entry so it would not
> > unwrap the input or output.
>
> "unwrapped" means just one element in the input parameter list
> corresponding to the input message, and a return type corresponding to
> the output message (the terminology being a little confusing)? In
> wrapped, if there is an output message, there is the usage of the Holder
> class and the elements of the output message are part of the input
> parameters, and a void return type?
In "unwrapped" or "bare", you get a single input and a single return. Like:
FooResponse doFoo(FooRequest r);
In "wrapped" mode (normally the default when possible), those
Request/Response objects are "unwrapped" into individual parameters, and the
runtime re-"wraps" them into the objects. Each property in the request is
mapped to a parameter. If the response only has a single property, it maps
to the return, but if the response has multiple properties, they are handled
via Holder parameters.
> The WSDL that I provided is an excerpt. In the other operations, where
> the input message name is not the same as the operation name, the
> corresponding code generated is unwrapped (in the above sense if that is
> correct). Is the default unwrapped for everything, or is it finer
> grained than that.
The JAXWS spec dictates when the operation needs to be made BARE. Section
2.3.1.2 says:
(i) The operation’s input and output messages (if present) each contain only a
single part
(ii) The input message part refers to a global element declaration whose
localname is equal to the operation name
(iii) The output message (if present) part refers to a global element
declaration
(iv) The elements referred to by the input and output message (if present)
parts (henceforth referred to as wrapper elements) are both complex types
defined using the xsd:sequence compositor
(v) The wrapper elements only contain child elements, they MUST not contain
other structures such as wildcards (element or attribute), xsd:choice,
substitution groups (element references are not permitted) or attributes;
furthermore, they MUST not be nillable.
If the above rules are not met, then the operation is output in "BARE" mode.
--
Daniel Kulp
dan@kulp.com
http://www.dankulp.com/blog
Re: code generation problem
Posted by David Robertson <dw...@lbl.gov>.
Daniel Kulp wrote:
> On Mon May 11 2009 5:19:06 pm David Robertson wrote:
>
>> I'm having a problem with the attached WSDL. It is valid, but the code
>> generated for the operation has the output elements, unwrapped, in the
>> parameter list and a void return type. I don't have the option of
>> changing the WSDL. Is this something that can be fixed with enough
>> binding entries, or would the problem be manifesting before it gets to
>> the binding.
>>
>> -David Robertson
>>
>
> This code is generating exactly per spec.
>
> You could switch it to "bare" mode with a binding entry so it would not unwrap
> the input or output.
>
>
"unwrapped" means just one element in the input parameter list
corresponding to the input message, and a return type corresponding to
the output message (the terminology being a little confusing)? In
wrapped, if there is an output message, there is the usage of the Holder
class and the elements of the output message are part of the input
parameters, and a void return type?
The WSDL that I provided is an excerpt. In the other operations, where
the input message name is not the same as the operation name, the
corresponding code generated is unwrapped (in the above sense if that is
correct). Is the default unwrapped for everything, or is it finer
grained than that.
-David Robertson
Re: code generation problem
Posted by Daniel Kulp <dk...@apache.org>.
On Mon May 11 2009 5:19:06 pm David Robertson wrote:
> I'm having a problem with the attached WSDL. It is valid, but the code
> generated for the operation has the output elements, unwrapped, in the
> parameter list and a void return type. I don't have the option of
> changing the WSDL. Is this something that can be fixed with enough
> binding entries, or would the problem be manifesting before it gets to
> the binding.
>
> -David Robertson
This code is generating exactly per spec.
You could switch it to "bare" mode with a binding entry so it would not unwrap
the input or output.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog