You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Jim Cross <Ji...@trx.com> on 2005/06/28 20:15:08 UTC

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?



Re: Client insists on sending xsi type

Posted by Anne Thomas Manes <at...@gmail.com>.
Perhaps the type isn't defined in the WSDL/Schema, therefore Axis must
specify the type.
Supply the WSDL and I'll take a look.

On 6/28/05, Jim Cross <Ji...@trx.com> wrote:
>  
> 
> 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? 
>