[jira] Reopened: (AXIS-581) setSchemaVersion() does not work

[ji...@apache.org]

Message:

   The following issue has been reopened.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-581

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-581
    Summary: setSchemaVersion() does not work
       Type: Bug

     Status: Reopened

    Project: Axis
 Components: 
             Serialization/Deserialization
   Versions:
             1.0

   Assignee: Davanum Srinivas
   Reporter: Brian Ewins

    Created: Fri, 20 Dec 2002 5:23 PM
    Updated: Mon, 12 Apr 2004 5:38 AM
Environment: Operating System: Windows NT/2K
Platform: PC

Description:
[I've marked severity major as this bug prevents interop with 1999 schema
services, but please mark it down if thats a non-goal]

I tried to use WSDL for a Soap 1.1/1999 Schema service with Axis as a client.
The service sent and recieved a single string. It would appear that what should
happen here is that WSDL2Java should generate code like:

MessageContext msgContext = _call.getMessageContext();   
msgContext.setSOAPConstants(SOAPConstants.SOAP11_CONSTANTS);
msgContext.setSchemaVersion(SchemaVersion.SCHEMA_1999);

WSDL2Java doesn't insert this code, but putting it in by hand doesn't help, for
many reasons. The packet that is sent uses both the 2001 XSI namespace and the
2001 XSD namespace, which causes validation failures on the 1999 service. 

Firstly, MessageContext sets the default encodingStyle without reference to the
value of soapConstants. This means that you need to set them separately:
msgContext.setEncodingStyle(msgConstants.getSOAPConstants().getEncodingURI());
This doesn't quite make sense; it looks like setSOAPConstants should have the
side effect of resetting the encoding style to the default.

Secondly, having got a correct encoding style, the type mappings are all wrong.
There is no registered type mapping for
{http://www.w3.org/1999/XMLSchema}string, so, no problem, lets register it by hand:
QName xmlType=new QName("http://www.w3.org/1999/XMLSchema", "string");
_call.registerTypeMapping(String.class,
  new QName("http://www.w3.org/1999/XMLSchema", "string"),
  new SimpleSerializerFactory(String.class, xmlType),
  new SimpleDeserializerFactory(String.class, xmlType));

This doesn't solve the problem. The packet Axis sends now looks like:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <ns1:XMLListForms
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="/jetforms/soap/Server.xml">
   <XMLRequest xsi:type="xsd:string"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">[data]</XMLRequest>
  </ns1:XMLListForms>
 </soapenv:Body>
</soapenv:Envelope>

Notice the envelope still uses the 2001 xsi namespace, but switches to 1999 for
xsd because of the extra type mapping. This xsi namespace is being set in
SerializationContextImpl.setTypeAttribute() to the hardcoded value
Constants.URI_DEFAULT_SCHEMA_XSI, when it should probably be be
schemaVersion.getXsiUri(). So, theres no way to fix this without altering the
code in Axis.

There are several bugs here but as they all end up breaking 1999 interop, I
thought I'd file this as one. The last bug in SerializationContextImpl is the
showstopper as it makes it impossible (as far as I can tell) to send the correct
xsi namespace. That bug is easy enough to fix but really all of the 1999 type
mappings should be registered too.  

I guess there's no impetus to integrate to broken 'legacy' interfaces like this
but it may surprise you to know the service I'm trying to talk to is in a /brand
new/ release of a product from Adobe. Eeech.


---------------------------------------------------------------------
JIRA INFORMATION:
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