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.