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