You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Bill Keese (JIRA)" <ax...@ws.apache.org> on 2005/01/31 10:08:20 UTC

[jira] Updated: (AXIS-1784) Axis client should not generate xsi:type attributes in document/literal or wrapped/literal mode

     [ http://issues.apache.org/jira/browse/AXIS-1784?page=history ]

Bill Keese updated AXIS-1784:
-----------------------------

    Attachment: array.zip

I tried against the latest version and it still happens (worse yet, printing the wrong type information).  So, I am attaching a testcase I wrote for another bug.  Just run with TCPMON and look at the request XML that the client sends.  Since I am sending basic types there should be no "xsi:type=..." information.

> Axis client should not generate xsi:type attributes in document/literal or wrapped/literal mode
> -----------------------------------------------------------------------------------------------
>
>          Key: AXIS-1784
>          URL: http://issues.apache.org/jira/browse/AXIS-1784
>      Project: Axis
>         Type: Bug
>     Versions: 1.2RC2
>     Reporter: Bill Keese
>     Priority: Minor
>  Attachments: array.zip
>
> Axis generates xsi:type=... attribute definitions even in literal mode.  It shouldn't.  The fix should be in SerializationContext:
>             sendXSIType = ( msgContext.getOperationUse() == Use.ENCODED );
> (or something like that).
> Also, ArraySerializer() has the following code which shouldn't be executed except for RPC/Encoded mode:
>             if (typeI != -1) {
>                 attrs.setAttribute(typeI,
>                                    schema.getXsiURI(),
>                                    "type",
>                                    qname,
>                                    "CDATA",
>                                    context.qName2String(soapArray));
>             } else {
>                 attrs.addAttribute(schema.getXsiURI(),
>                                    "type",
>                                    qname,
>                                    "CDATA",
>                                    context.qName2String(soapArray));
>             }
> Workaround:
> In client code, do
>      call.setProperty(Call.SEND_TYPE_ATTR, Boolean.FALSE);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira