Doug,
Thank you for the clarification. I am now generating the server/client
classes from the WSDL using the -f:wsi, -f:documentliteral, and -f:unwrap
options. I've also modified the WSDL to name the elements the same as the
operations. Everything appears to be working fine now, and no wrappers are
generated. The use of these three options shouldn't cause any additional
problems, right?
Thank you,
- Ryan
-----Original Message-----
From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
Sent: Wednesday, November 03, 2004 6:17 PM
To: users_at_jax-rpc.dev.java.net
Subject: Re: Generated wrapper classes for document style web services
Ryan LeCompte wrote:
>Doug,
>
>I'd like to reiterate that with the "-f:wsi" operation wrappers are
>generated, and without this option wrappers are not generated. So
>clearly the -f:wsi option is changing the generated code.
>
Ryan, sorry about the confusion. Yes, the method signatures do change with
the -f:wsi option, however, what actually goes over the wire does not. If
the operation is unwrapped, the JAXRPC runtime still packages them up inside
a single element on the wire.
The name of that element is the name specified in the WSDL.
> I'd also like to refer you
>to my earlier posting which demonstrates how a DII client does not work
>for the same TestWebService WSDL that I've pasted in a previous e-mail.
>We've come to the conclusion that the DII client isn't working because
>the complex type/element names are not the same as the operation names.
>Why does the element name have to be the same name as the operation
>name in order for unwrapping to occur?
>
The JAXRPC spec states:
When mapping document style operations, in addition to the regular mapping,
JAX-RPC implementations are required to support the so-called "wrapper"
style, in which the logical parameters of an operation are wrapped inside a
xsd:sequence element named after the operation.
In order to qualify as using the "wrapper" style, an operation must fulfill
the following
conditions:
. its input and output messages (if present) must contain exactly one part;
. such a part must refer to an element named after the operation; . such an
element (a wrapper) must be of a complex type defined using the xsd:sequence
compositor and containing only elements declarations.
In this case, implementations must be able to discard the wrapper elements
and treat their children as the actual parameters of the operation. Please
refer to section 6.4.3 below for an example.
This is how JAXRPC determines that a wrapper was intended. Since there is no
direct way in the WSDL to specify that an element is a wrapper, the JAXRPC
spec defined the requirements for an element to qualify as a wrapper.
>Also, keep in mind that the same WSDL when passed to .NET's wsdl.exe
>utility does not generate any wrappers.
>
>
OK, I believe you. However, we are implementing the JAXRPC spec correctly.
Thank you for using JAXRPC.
>-- Ryan
>
>
>-----Original Message-----
>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>Sent: Wednesday, November 03, 2004 4:30 PM
>To: users_at_jax-rpc.dev.java.net
>Subject: Re: Generated wrapper classes for document style web services
>
>Actually, at this point I believe it is not a bug as the element name
>of the input message does not match the operation name. If the WSDL
>had the following it would unwrap.
>
> <types>
> <schema
> ....
> <element name="handleData" type="tns:tData"/>
> </schema>
> </types>
>
> <message name="TestWebService_handleData">
> <part name="parameters" element="xsdns:handleData"/>
> </message>
>
>Ryan LeCompte wrote:
>
>
>
>>Doug,
>>
>>If I don't use the -f:wsi switch then the wrappers go away. However,
>>shouldn't I keep the -f:wsi switch so that the generated server
>>classes are WSI compliant? I don't mind having the wrappers if it
>>means that the generated Java classes are WSI compliant. What
>>specifically are you saying is a bug? The fact that -f:wsi generates
>>the wrapper classes or the fact that the -f:wsi with the -f:unwrap
>>feature is still generating wrappers when it shouldn't be?
>>
>>-- Ryan
>>
>>-----Original Message-----
>>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>>Sent: Wednesday, November 03, 2004 3:52 PM
>>To: users_at_jax-rpc.dev.java.net
>>Subject: Re: Generated wrapper classes for document style web services
>>
>>Ryan,
>>Looks like a bug. Try not using the -f:wsi switch at all.
>>
>>Ryan LeCompte wrote:
>>
>>
>>
>>
>>
>>>Sure, the WSDL is:
>>>
>>><?xml version="1.0" encoding="UTF-8"?> <definitions
>>>name="TestWebService"
>>> targetNamespace="urn:com.test.webservice/wsdl/TestWebService"
>>> xmlns:tns="urn:com.test.webservice/wsdl/TestWebService"
>>> xmlns:xsdns="urn:com.test.webservice/types/TestWebService"
>>> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>>> xmlns="http://schemas.xmlsoap.org/wsdl/">
>>> <types>
>>> <schema
>>>targetNamespace="urn:com.test.webservice/types/TestWebService"
>>> xmlns:tns="urn:com.test.webservice/types/TestWebService"
>>> xmlns="http://www.w3.org/2001/XMLSchema">
>>>
>>> <complexType name="tData">
>>> <sequence>
>>> <element name="arrayOfData"
>>>type="tns:tDatum" nillable="false"
>>> minOccurs="1"
>>>maxOccurs="unbounded"/>
>>> </sequence>
>>> </complexType>
>>> <complexType name="tDatum">
>>> <sequence>
>>> <element name="dataOne"
>>>type="string" nillable="false"/>
>>> <element name="dataTwo"
>>>type="string" nillable="false"/>
>>> </sequence>
>>> </complexType>
>>> <element name="data" type="tns:tData"/>
>>> </schema>
>>> </types>
>>>
>>> <message name="TestWebService_handleData">
>>> <part name="parameters" element="xsdns:data"/>
>>> </message>
>>>
>>> <portType name="TestWebServicePortType">
>>> <operation name="handleData">
>>> <input message="tns:TestWebService_handleData"/>
>>> </operation>
>>> </portType>
>>>
>>> <binding name="TestWebServiceBinding"
>>>type="tns:TestWebServicePortType">
>>> <soap:binding
>>>transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
>>> <operation name="handleData">
>>> <soap:operation
>>>soapAction="TestWebService/handleData"/>
>>> <input>
>>> <soap:body use="literal"/>
>>> </input>
>>> </operation>
>>> </binding>
>>>
>>> <service name="TestWebService">
>>> <port name="TestWebServicePort"
>>>binding="tns:TestWebServiceBinding">
>>> <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
>>> </port>
>>> </service>
>>></definitions>
>>>
>>>-----Original Message-----
>>>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>>>Sent: Wednesday, November 03, 2004 12:04 PM
>>>To: users_at_jax-rpc.dev.java.net
>>>Subject: Re: Generated wrapper classes for document style web
>>>services
>>>
>>>Can you include the WSDL?
>>>
>>>Ryan LeCompte wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>I should also mention that given the same WSDL file, .NET's "wsdl.exe"
>>>>utility generates an implementation that doesn't use any wrapper
>>>>classes in the operation definitions.
>>>>
>>>>- Ryan
>>>>
>>>>-----Original Message-----
>>>>From: Ryan LeCompte [mailto:ryan.lecompte_at_pangonetworks.com]
>>>>Sent: Wednesday, November 03, 2004 11:37 AM
>>>>To: 'users_at_jax-rpc.dev.java.net'
>>>>Subject: RE: Generated wrapper classes for document style web
>>>>services
>>>>
>>>>Doug,
>>>>
>>>>I've tried passing the -f:unwrap option along with -f:wsi and
>>>>-f:documentliteral, but it still generates the wrapper classes.
>>>>
>>>>-- Ryan
>>>>
>>>>-----Original Message-----
>>>>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>>>>Sent: Wednesday, November 03, 2004 11:41 AM
>>>>To: users_at_jax-rpc.dev.java.net
>>>>Subject: Re: Generated wrapper classes for document style web
>>>>services
>>>>
>>>>This was done to behave more like .Net. Try adding the -f:unwrap
>>>>option to wscompile.
>>>>
>>>>Ryan LeCompte wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hello all,
>>>>>
>>>>>When going from a document style WSDL file to Java interfaces, I
>>>>>notice that the generated endpoint Java interface uses "wrapper"
>>>>>arguments instead of the original types defined in the WSDL. The
>>>>>wscompile command that I'm using is:
>>>>>
>>>>>wscompile -gen:server -model model -f:wsi -f:documentliteral -keep
>>>>>-s generated -d output/server -classpath . config.xml
>>>>>
>>>>>
>>>>>
>>>>>When I provide my "servant" implementation of the generated
>>>>>interface, I have to actually use the getXXX() methods
>>>>>
>>>>>on the generated wrapper classes to get at the underlying data
>>>>>structures
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>(an array of X objects, for example).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Why are the wrapper classes needed when -f:wsi is specified?
>>>>>
>>>>>
>>>>>
>>>>>-- Ryan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--------------------------------------------------------------------
>>>>- To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>
>>>>
>>>>--------------------------------------------------------------------
>>>>- To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net