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

["Bill Keese (JIRA)" <ax...@ws.apache.org>]

     [ http://issues.apache.org/jira/browse/AXIS-1784?page=comments#action_58132 ]
     
Bill Keese commented on AXIS-1784:
----------------------------------

I just noticed that Call.setOperation(String opName) does this logic:

        Use use = bEntry.getInputBodyType(bop.getOperation());
        setOperationUse(use);
        if (use == Use.LITERAL) {
            // Turn off encoding
            setEncodingStyle(null);
            // turn off XSI types
            setProperty(org.apache.axis.client.Call.SEND_TYPE_ATTR, Boolean.FALSE);
        }

Maybe the logic should be inside of setOperationUse() rather than inside setOperation().  Then it would work even when there wasn't a WSDL file.

Also, note that (as stated above) ArraySerializer doesn't strictly obey the SEND_TYPE_ATTR flag.

> 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

>
> 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