axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Thomas Manes <atma...@gmail.com>
Subject Re: Client insists on sending xsi type
Date Wed, 29 Jun 2005 20:55:48 GMT
It depends what the WSDL says...

If the WSDL defines the type as
http://www.something.com/schema/20050101}QueueName and the application
instead sends xsd:string, then Axis is *required* to send the xsi:type
information.

If the WSDL defines the type as xsd:string, then it might be a bug.

Anne

On 6/29/05, Jim Cross <Jim.Cross@trx.com> wrote:
>  
>  
> 
> Workaround found: 
> 
> The generated proxy code contained this line (word "something" was
> substituted for the real name): 
> 
>         elemField.setXmlType(new
> javax.xml.namespace.QName("http://www.something.com/schema/20050101",
> "QueueName")); 
> 
> When it was changed to this: 
> 
>         elemField.setXmlType(new
> javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema",
> "string")); 
> 
> It works correctly and does not send the xsi:type. 
> 
> Is this a bug in the wsdl2java, a bug in the serialization, or a problem
> with the schema that was used to generate to the proxy?
>  
>  
> 
>  -----Original Message----- 
> From:   Jim Cross  
> Sent:   Tuesday, June 28, 2005 2:15 PM 
> To:     'axis-dev@ws.apache.org' 
> Subject:        Client insists on sending xsi type 
> 
> I'm assessing a server from the client side. I'm not sure what the server is
> written with. I've tried this with 1.1, 1.2, and 1.2.1. 
> 
> The generated proxies have this statement before the service request. 
> 
>        
> _call.setProperty(org.apache.axis.client.Call.SEND_TYPE_ATTR,
> Boolean.FALSE); 
> 
> I can also confirm that 
> 
> MessageContext property name=sendXsiTypes value=false 
> 
> Nevertheless, with a particular string array, the client insists on
> generating 
> 
> xsi:type="xsd:string" on the element 
> 
> Removing the xsi:type and sending the SOAP XML via a raw post to the server
> works, so it is definite that this is problem. 
> 
> As far as I tell from some limited debugging, the code gets deep into its
> serialization and compares the xmlType with an actualType (not sure where or
> how this is created or what purpose it serves). If these are different, it
> seems to generate the xsi:type no matter what the property setting is. 
> 
> Any idea how to work around this? 
>

Mime
View raw message