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. 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? Also, keep in mind that the same WSDL when passed to
.NET's wsdl.exe utility does not generate any wrappers.
-- 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