DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15581>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15581 setSchemaVersion() does not work Summary: setSchemaVersion() does not work Product: Axis Version: 1.0 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Serialization/Deserialization AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] [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.
