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