You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Shashi Rai <sr...@adobe.com> on 2004/08/12 23:34:53 UTC
Serialization error with Axis1.2 rpc/encoded service and gSOAP
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>
AdminClient gives 401 error on localhost???
Posted by Jonathan DiCarlo <jd...@mcs.anl.gov>.
Hello everybody,
I'm having trouble deploying my first webservice on Axis. (I bet you hear
that a lot). Specifically, I get a 401:unauthorized error when I run
AdminClient (or the ant task <axis-admin>). The fine print in the error
message says "Remote administration access not allowed". This is strange
because it is running on my local machine.
I searched the archives of this list, and I found some other people who
had had the same problem. There was a solution given that involved editing
server-config.wsdd to allow remote administrator access. But I would
really prefer not to have to do that, as it's a security hole. I really
want to find out WHY Axis thinks I am attempting remote access when I am
actually on the same machine.
I have searched the web and the Axis docs extensively to no avail. They
all seem to indicate that I'm doing everything right. If anyone would be
willing to help me out a bit here, I will love you forever.
Details of my setup follow:
I am using Axis 1.1 running inside Tomcat 4.1.18. It is running on port
10081 instead of the usual 8080. The happyaxis.jsp page shows that all
needed components are installed, and one optional piece is missing
(org.apache.xml.security.Init).
The problem comes when I try to deploy a simple hello-world web service
using a wsdd (which was generated using wsdl2java). In ant, I try an
axis-admin task, as follows:
<axis-admin
port="10081"
hostname="localhost"
xmlfile="./output/axisAutoSource/jono/subcreated/deploy.wsdd"
debug="true"
url="http://localhost:10081/services/AdminService"
username="repotest"
password="repotest"
/>
I have tried many, many variations on this. I get the same result if I
use hostname="localhost" and servletpath="axis/services/AdminService"
instead of using a URL. I also get the same result if I use the
command line java org.apache.axis.client.AdminClient instead of ant. I
have done the obvious reality-checks, like making sure that Tomcat is
running and that the path to deploy.wsdd is correct.
I also enabled the admin servlet by uncommenting the appropriate lines in
web.xml, but that didn't help. If I go to
http://localhost:10081/axis/servlet/AdminServlet, I see a page that just
says:
Server is running
Current load = 1
I guess I could also try editing server-config.wsdd by hand (i.e. copy it
over from src/ and then copy the appropriate things into it from my
deploy.wsdd.) but I want to be able to deploy with an ant task
instead of manually.
Thanks in advance, if you read this far!
Re: Serialization error with Axis1.2 rpc/encoded service and gSOAP
Posted by Frank Cohen <fc...@pushtotest.com>.
I'd like to chime in on this topic... A TestMaker user at SAP posted an
email saying he couldn't get TestMaker to deserialize a soapenc:string
response from Axis 1.3 beta 3. TestMaker uses Apache SOAP as its SOAP
stack. Anyone that's followed my work knows that I urge developers to
use Document-encoding because SOAP RPC encoded Web Services are not
scalable for large payloads and lots of concurrent requests. Details on
my findings are at
http://www-106.ibm.com/developerworks/webservices/library/ws-soapenc/.
Sun and IBM seem oblivious to this - or al least they're not
highlighting it to developers - so you've still got lots of people out
there using RPC encoding and expecting their SOAP stack to deserialize
xsd:string Element types.
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:an4m@cs.virginia.edu]
> Sent: Friday, August 13, 2004 11:51 AM
> To: axis-user@ws.apache.org
> 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>
> :
> :
> :
>
>
RE: Serialization error with Axis1.2 rpc/encoded service and gSOAP
Posted by Anne Thomas Manes <an...@manes.net>.
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:an4m@cs.virginia.edu]
Sent: Friday, August 13, 2004 11:51 AM
To: axis-user@ws.apache.org
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>
:
:
:
RE: Serialization error with Axis1.2 rpc/encoded service and gSOAP
Posted by Shashi Rai <sr...@adobe.com>.
Anand,
I face exactly the same issues. My Axis service is rpc/encoded and returns
arrays of complex objects/strings etc. and uses enums etc. My client is
gSOAP and it fails to generate correct stubs and compile it for Axis1.2.
Unfortunately I can not switch to doc/lit but I need to migrate to Axis1.2
in order to create new WS-I compliant web services. I am trying to avoid
using Axis1.1 as well as Axis1.2 on the server, and so I am currently using
the workaround to get around this problem.
Any idea how to resolve this?
Thanks
--shashi
-----Original Message-----
From: Anand Natrajan [mailto:an4m@cs.virginia.edu]
Sent: Friday, August 13, 2004 8:51 AM
To: axis-user@ws.apache.org
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>
:
:
:
Re: Serialization error with Axis1.2 rpc/encoded service and gSOAP
Posted by Anand Natrajan <an...@cs.virginia.edu>.
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>
:
:
: