Ryan LeCompte wrote:
>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?
>
>
I don't believe so. Just for you knowledge, the -f:documentliteral flag
and the -f:rpcliteral flags are ignored when processing a WSDL.
This is because the WSDL itself defines if it is doc/lit, rpc/lit or
rpc/encoded.
Thanks again and good luck with your project.
>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
>
>
>
---------------------------------------------------------------------
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