The workarounds I proposed to the TestMaker user are: 1) Use Axis 1.2 2) Have PushToTest patch TestMaker to accept soapenc:string types.
Neither of these is very good. I wish Axis 1.3 would be more flexible and support the old type style too.
-Frank
---
Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426
Author of "Java Testing and Design: From Unit Tests to Automated Web Tests"
from Prentice Hall, details at http://thebook.pushtotest.com
On Aug 13, 2004, at 11:18 AM, Anne Thomas Manes wrote:
The reason why WS-I Basic Profile excludes use of SOAP encoding is that it
isn't fully specified, and therefore you will almost certainly encounter
interoperability issues.
To quote the SOAP 1.1 spec, Section 5.1.2 Strings [1]:
<soapSpecExcerpts>
" The datatype "string" is defined in "XML Schema Part 2: Datatypes"
Specification [11]. Note that this is not identical to the type called
"string" in many database or programming languages, and in particular may
forbid some characters those languages would permit. (Those values must be
represented by using some datatype other than xsd:string.)
...
"(In this example, the type SOAP-ENC:string is used as the element's type as
a convenient way to declare an element whose datatype is "xsd:string" and
which also allows an "id" and "href" attribute. See the SOAP Encoding schema
for the exact definition. Schemas MAY use these declarations from the SOAP
Encoding schema but are not required to.)"
</soapSpecExcerpts>
Given the use of "MAY" rather than "MUST" in the specification, there isn't
a right way versus wrong way to encode a string. As long as the element
contains content that is consistent with xsd:string, it is absolutely
correct to assign it a type of xsd:string. But if the element contains an
"id" or "href" attribute, then it MUST be assigned to a type that allows
this type of content (such as soapenc:string).
Either way, .NET should be able to process both xsd:string and
soapenc:string. But I expect that Microsoft has little, if any, incentive to
invest in fixes to SOAP encoding. SOAP encoding has been outlawed by WS-I
BP, and it is an optional feature in SOAP 1.2.
It's one thing to maintain existing rpc/encoded services, but you shouldn't
be building new rpc/encoded applications. SOAP encoding is a dead-end
technology.
[1] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383515
Best regards, Anne
-----Original Message-----
From: Anand Natrajan [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 11:51 AM
To: [EMAIL PROTECTED]
Subject: Re: Serialization error with Axis1.2 rpc/encoded service and gSOAP
Shashi,
I am very familiar with that problem (I entered the bug report to which you
allude in your email). Yes, this is a serious interoperability problem.
However, I now agree with Davanum Srinivas that Axis 1.2 is actually doing
the correct thing when it assigns the soapenc namespace to string.
Apparently Axis 1.1 had a bug that made it assign the xsd namespace.
As I mention in my report, I face this problem when my Axis service
(rpc/encoded version) returns an array of string and I try to consume the
response in a VB .NET client. If I change any one thing - use doc/lit
instead of rpc/enc, or use a non-.NET client, or use Axis 1.1, or return a
single string instead of an array - everything works.
After reading the SOAP specs, I'm becoming convinced that it is actually
.NET that is adhering to the wrong standard. I've entered a report in MDSN
Product Feedback Centre as well, with no response. I seriously hope this
issue is addressed, but currently, I am being forced to look at alternative
ways of returning the problematic data.
Anand
On Thu, 12 Aug 2004, Shashi Rai wrote:
: Hi All,
:
: I have been using Axis1.1 on server and gSOAP on the client for long time
: and everything has been working fine. I am trying to migrate to Axis1.2
and
: picked up bits on Aug5. When I tried to generate header and stubs and
: compile the client project, it failed. After further investigation, I find
: that in Axis1.2, somehow string are soapenc:string rather than xsd:string.
I
: usually use wsdd file to deploy webservice in Axis. If I use following
: typeMapping, the WSDL contains xsd:string and everything works fine.
: Otherwise it has soapenc:string and client code fails.
:
: <typeMapping
: qname="tns:string"
: type="java:java.lang.String"
: serializer="org.apache.axis.encoding.ser.SimpleSerializerFactory"
: deserializer="org.apache.axis.encoding.ser.SimpleDeserializerFactory"
: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
: />
:
: While including the above solves the problem with soapenc, it introduces a
: different problem. When my webservice class is invoked by Axis, the
: parameters of type string in the method are empty string.
:
: The current workaround for me is generate WSDL by including above
: typemapping so that gSOAP client code is happy. and then remove the type
: mapping on the server server.
:
: Question: is this a bug in Axis1.2 and is it fixed? I noticed a similar
: issue at:
: http://issues.apache.org/jira/browse/AXIS-1467
:
:
: Thanks
:
: --shashi
:
:
: Here it the partial wsdd I use:
:
: <deployment xmlns="http://xml.apache.org/axis/wsdd/";
: xmlns:java="http://xml.apache.org/axis/wsdd/providers/java";
: xmlns:tns="http://www.w3.org/2001/XMLSchema";
: xmlns:ns1="http://edc.adobe.com/edcwebservice";
: xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance";
: >
: <service name="urn:EDCLicenseService" provider="java:RPC" style="rpc"
: use="encoded" >
: <parameter name="className"
: value="com.adobe.edc.server.webservices.EDCLicenseService"/>
: <parameter name="allowedMethods" value="getServerPreferences "/>
: <operation name="getServerPreferences"
qname="ns1:getServerPreferences"
: returnQName="returnServerPreferences"
: returnType="ns1:ServerPreference" >
: <fault name="EDCFault" qname="fns:fault"
: xmlns:fns="http://edc.adobe.com/EDCFaults";
:
: class="com.adobe.edc.server.errors.exception.EDCWebserviceException"
: type="ns1:EDCFault" />
: </operation>
: <typeMapping
: qname="ns1:EDCFault"
:
: type="java: com.adobe.edc.server.errors.exception.EDCWebserviceException"
: serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
:
deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
: />
: <typeMapping
: qname="ns1:AuthScheme"
: languageSpecificType="java:com.adobe.edc.server.soap.AuthSchemeDTO"
: serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
: deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
: />
: <typeMapping
: qname="ns1:AuthSchemes"
:
languageSpecificType="java:com.adobe.edc.server.soap.AuthSchemeDTO[]"
: serializer="org.apache.axis.encoding.ser.ArraySerializerFactory"
:
deserializer="org.apache.axis.encoding.ser.ArrayDeserializerFactory"
: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
: />
: <!--
: <typeMapping
: qname="tns:string"
: type="java:java.lang.String"
: serializer="org.apache.axis.encoding.ser.SimpleSerializerFactory"
: deserializer="org.apache.axis.encoding.ser.SimpleDeserializerFactory"
: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
: />
: -->
: </service>
: </deployment>
:
:
:
