Well, it's quite a bit more complicated for runtime as well as code
generation. That's more of an excuse though, not a technical
reason. By not needing to traverse the extensions and stuff,
determining in/out and out params and stuff is a bit easier. Dealing
with the unwrapping/wrapping of the wrapper objects is also a bit
easier as well.
Of course, now there is also the "backwords compatible" issue. Adding
support for it would have to be an optional processing flag or
something.
Dan
On May 13, 2008, at 4:00 PM, JSP wrote:
Thanks for the quick response. It is much appreciated.
It seems like the spec is a little vague on this topic.
Is there any technical reason why this could not be unwrapped? It
seems
like the spec could be interpreted to also include an extension that
itself
is only defined by an xsd:sequence and any of its extensions would
follow
the same rule, etc, etc.
dkulp wrote:
I believe this has to do with the JAXWS spec's definition for when to
unwrap or not. Looking in 2.3.1.2 of the jaxws spec, it
specifically
says it can unwrap it ONLY if:
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
I think the complexContext + extension things take it outside of that
rule and thus don't unwrap.
Dan
On May 13, 2008, at 11:55 AM, JSP wrote:
I am trying to understand if this behavior I am seeing is expected
and if so,
can someone explain why.
I have a wsdl where my request and response elements extend another
element.
When the extension element is included my web method is generated
with a
@SOAPBinding annotation with a bare parameter style. However, if I
remove
the extension element, I get REsponseWrapper, RequestWrapper and
WebResult
annotations.
Here is a snippet of my wsdl:
<xs:element name="GetAddress">
<xs:complexType>
<xs:complexContent>
<xs:extension base="tns:simpleBeanInfo">
<xs:sequence>
<xs:element form="qualified" minOccurs="0" name="addressInput"
type="tns:addressInputType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
--- Other schema def ----
<wsdl:message name="GetAddress">
<wsdl:part element="tns:GetAddress" name="parameters">
</wsdl:part>
</wsdl:message>
<wsdl:message name="GetAddressResponse">
<wsdl:part element="tns:GetAddressResponse" name="parameters">
</wsdl:part>
</wsdl:message>
<wsdl:portType name="AddressPort">
<wsdl:operation name="GetAddress">
<wsdl:input message="tns:GetAddress" name="GetAddress">
</wsdl:input>
<wsdl:output message="tns:GetAddressResponse"
name="GetAddressResponse">
</wsdl:output>
</wsdl:operation>
</wsdl:portType>
And this is what is generated:
@WebService(targetNamespace = "urn:AddressTNS", name =
"AddressPort")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
public interface AddressPort {
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@WebResult(name = "GetAddressResponse", targetNamespace =
"urn:AddressTNS", partName = "parameters")
@WebMethod(operationName = "GetAddress", action =
"urn:GetAddress")
public addresstns.GetAddressResponse getAddress(
@WebParam(partName = "parameters", name = "GetAddress",
targetNamespace = "urn:AddressTNS")
GetAddress parameters
);
}
Now if I remove the xs:complexContent and the xs:extension elements,
my
generated code will look like this:
@WebService(targetNamespace = "urn:AddressTNS", name =
"AddressPort")
public interface AddressPort {
@ResponseWrapper(localName = "GetAddressResponse",
targetNamespace =
"urn:AddressTNS", className = "addresstns.GetAddressResponse")
@RequestWrapper(localName = "GetAddress", targetNamespace =
"urn:AddressTNS", className = "addresstns.GetAddress")
@WebResult(name = "addressOutput", targetNamespace = "")
@WebMethod(operationName = "GetAddress", action =
"urn:GetAddress")
public addresstns.AddressOutputType getAddress(
@WebParam(name = "addressInput", targetNamespace = "")
addresstns.AddressInputType addressInput
);
}
I am wondering why they would be different? I would expect both to
generate
like the second. If this is behaving as expected can someone tell
me why
they should be different?
I am using CXF 2.0.5.
Thanks
--
View this message in context:
http://www.nabble.com/Web-methods-generated-differently-when-request-response-extend-another-class-tp17212004p17212004.html
Sent from the cxf-user mailing list archive at Nabble.com.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--
View this message in context:
http://www.nabble.com/Web-methods-generated-differently-when-request-response-extend-another-class-tp17212004p17217092.html
Sent from the cxf-user mailing list archive at Nabble.com.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
