axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sc...@us.ibm.com
Subject RE: Axis Chokes on Complex Types from MS Soap 3.0
Date Tue, 13 Aug 2002 18:11:54 GMT
Glen said:
| I'm not precisely sure when names *wouldn't* be local to their containing
types...


Is this what is meant by local to the containing type ?

<complexType name="foo">
  <sequence>
     <element name="a" type="xsd:string"/>   <!-- the name a is local to
the containing type -->
     <element ref="b"/>                      <!-- the name b is not local
to the containing type -->
  </sequence>
</complexType>

<element name="b" type="xsd:string"/>

Rich Scheuerle
IBM WebSphere & Axis Web Services Development
512-838-5115  (IBM TL 678-5115)


                                                                                         
                                       
                      Glen Daniels                                                       
                                       
                      <gdaniels@macrome        To:       "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
                  
                      dia.com>                 cc:                                    
                                          
                                               Subject:  RE: Axis Chokes on Complex Types
from MS Soap 3.0                       
                      08/13/2002 09:52                                                   
                                       
                      AM                                                                 
                                       
                      Please respond to                                                  
                                       
                      axis-dev                                                           
                                       
                                                                                         
                                       
                                                                                         
                                       




Ah, here's the issue.

>From the SOAP spec [1]:

"A Compound Value is encoded as a sequence of elements, each accessor
represented by an embedded element whose name corresponds to the name of
the accessor. Accessors whose names are local to their containing types
have unqualified element names; all others have qualified names (see also
section 5.4)."

In other words, SOAP encoding in the case where "names are local to their
containing types" trumps the schema, and requires unqualified elements.
I've just fixed our BeanSerializer/BeanDeserializer code to account for
this and am rerunning the tests to make sure all is well.  I'm not
precisely sure when names *wouldn't* be local to their containing types (I
guess if they somehow were direct representations of another type/schema,
but I don't think that's really doable in most programming languages), so
perhaps a bit more research is warranted, but this seems like the way to go
for now.

Give me a little while, and then I'll check in the changes if all is
successful.  (I'll bet most toolkits just ignore the namespace entirely.)

--Glen

[1] http://www.w3.org/TR/SOAP/#_Toc478383512

> -----Original Message-----
> From: Riggs, David [mailto:driggs@asset.com]
> Sent: Tuesday, August 13, 2002 10:22 AM
> To: axis-dev@xml.apache.org
> Subject: RE: Axis Chokes on Complex Types from MS Soap 3.0
>
>
> I have not tried a .NET client, only Axis (which works if
> I manually remove the namespace from the generated code)
> and I've witnessed a VB client consume the service while
> sitting on the same machine as the provider. I do not have
> access currently to either the client nor server VB code
> however...though the developer demonstrated both sending
> the structs as typed data and as xsd:anyType. Interestingly,
> the MSSTK explicitly sends the type across the wire when
> the schema has declared an element of type='xsd:anyType'
> (making the WSDL useless for autogenerating client-side
> code, since every method appears to return type Object),
> but does NOT send the type across the wire when it has
> been explicitly stated (eg. type='xsd:integer') in the
> WSDL.
>
> I may try to get a .NET client up if I have time, but we
> would like to deploy a pure Java solution...the code
> generation of Axis makes it very desirable, Sun's JWSDP
> is another option.
>
> David A. Riggs
> Science Applications International Corp.
>
> > -----Original Message-----
> > From: Scott Nichol [mailto:snicholnews@scottnichol.com]
> > Sent: Monday, August 12, 2002 2:41 PM
> > To: axis-dev@xml.apache.org
> > Subject: Re: Axis Chokes on Complex Types from MS Soap 3.0
> >
> >
> > David,
> >
> > I have not seen you mention whether or not you've tried a
> > .NET client against this WSDL.  Have you?  I am curious about
> > the result.
> >
> > Scott Nichol
> >
> > ----- Original Message -----
> > From: "Riggs, David" <driggs@asset.com>
> > To: <axis-dev@xml.apache.org>
> > Sent: Monday, August 12, 2002 2:19 PM
> > Subject: RE: Axis Chokes on Complex Types from MS Soap 3.0
> >
> >
> > I posted the following message to
> > microsoft.public.xml.soapsdk and
> > microsoft.public.msdn.soaptoolkit, if I get any useful
> > response I'll post here (or at least a link to the
> > groups.google archive). Thanks for your help!
> > ------------------------------------------------------------------
> >
> > From: driggs@asset.com (David A. Riggs)
> > Newsgroups: microsoft.public.msdn.soaptoolkit
> > Subject: Complex Type Namespacing Problem With MSSTK3
> > NNTP-Posting-Host: 192.131.125.2
> > Message-ID: <1745c75b.0208120933.636eeb2f@posting.google.com>
> >
> > I've developed a test web service that returns a complex data type
> > (struct)
> > with MSSTK3 as the provider. The client side is a non-MS
> > toolkit, and is complaining that the SOAP response is not
> > what it expects given the WSDL.
> >
> > My complex data type looks like this (as generated by
> > MSSTK3's generic type
> > mapper):
> > ----------- WSDL Excerpt -----------
> > <complexType name="Mission">
> >    <sequence>
> >       <element name="MissionName" type="string" />
> >       <element name="MissionNumber" type="int" />
> >    </sequence>
> > </complexType>
> > ------------------------------------
> >
> > The actual SOAP response is pasted below, note the following
> > facts about it:
> > - There is no default namespace declared anywhere in the document
> > - An xsd:type is explicitly declared for the parent element
> > of the complex type
> > - An xsd:type is NOT declared for the child elements of the
> > complex type
> >
> > It appears to me that these child elements do not belong to
> > any namespace, and as such, my client app (Apache Axis beta
> > 3) rejects the SOAP envelope when it gets to the MissionName
> > element (complaining 'Invalid element in org.tempuri.Mission
> > - MissionName').
> >
> > Can anyone shed any light on this matter?
> >
> > ----------- MSSTK3 SOAP Response --------------
> > <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> > <SOAP-ENV:Envelope xmlns:SOAPSDK1="http://www.w3.org/2001/XMLSchema"
> > xmlns:SOAPSDK2="http://www.w3.org/2001/XMLSchema-instance"
> > xmlns:SOAPSDK3="http://schemas.xmlsoap.org/soap/encoding/"
> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
> > <SOAP-ENV:Body
> > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
> > <SOAPSDK4:GetMissionsObjResponse
> > xmlns:SOAPSDK4="http://tempuri.org/TestWebService/message/">
> > <Result href="#id1"/>
> > </SOAPSDK4:GetMissionsObjResponse>
> > <SOAPSDK5:Mission
> > xmlns:SOAPSDK5="http://tempuri.org/TestWebService/type/"
> > id="id1" SOAPSDK3:root="0" SOAPSDK2:type="SOAPSDK5:Mission">
> > <MissionName>Test Value</MissionName>
> > <MissionNumber>42</MissionNumber> </SOAPSDK5:Mission>
> > </SOAP-ENV:Body> </SOAP-ENV:Envelope>
> > -----------------------------------------------
> >
> > Thanks,
> > David A. Riggs
> > Science Applications International Corp.
> >
> >
> >
>




Mime
View raw message