axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <t...@macromedia.com>
Subject RE: Axis 1.2 RC1 release red flag
Date Mon, 11 Oct 2004 14:30:17 GMT

Just an update.

I have been fixing some problems in the ArraySerializer that have been
causing grief.  In particular, we were sending xsi:type attributes for
arrays that looked like this:

<columnList soapenc:arrayType="soapenc:string[5]"
            xsi:type="ns1:ArrayOf_xsd_string"
            xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
  <item xsi:type="soapenc:string">foo</item>
  <item xsi:type="soapenc:string">boo</item>
  <item xsi:type="soapenc:string">too</item>
  <item xsi:type="soapenc:string">loo</item>
  <item xsi:type="soapenc:string">moo</item>
</columnList>

The type should be: xsi:type="soapenc:Array".  This helped quite a bit.
This change was bad because Axis checks the xsi:type *before* it checks to
see if we have soapenc:arrayType attributes (see
DeserializationContext.java, getTypeFromAttributes(), line 370).  The
functional tests didn't catch this because when you run WSDL2Java to create
server-side stuff, the deploy.wsdd will contain type mappings for
"ns1:ArrayOf_xsd_string" and friends.  I assume these changes were made for
doc/lit, where these type mappings are probably going to be required. :-(

See the changes I will check in shortly for code details, but basically I
made sure the xsi:type is sent in the ArraySerializer if we are doing SOAP
encoding.

I am now struggling with a change that happened I believe because of changes
made to the TypeMapping system.  We used to send the above array as:
soapenc:arrayType="xsd:string[5]" we now send it as a soapenc:string[5].


The WSDL for this rpc/encoded .NET service has this in the Schema:
<definitions xmlns:s=http://www.w3.org/2001/XMLSchema ...>
...

<s:complexType name="ArrayOfString">
 <s:complexContent mixed="false">
  <s:restriction base="soapenc:Array">
   <s:attribute d7p1:arrayType="s:string[]" 
                ref="soapenc:arrayType"
                xmlns:d7p1="http://schemas.xmlsoap.org/wsdl/" />
  </s:restriction>
 </s:complexContent>
</s:complexType>

Axis sends:

<thestringarray 
      soapenc:arrayType="soapenc:string[5]"
      xsi:type="soapenc:Array"
      xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
 <item>a</item>
 <item>b</item>
 <item>c</item>
 <item>d</item>
 <item>e</item>
</thestringarray>

The .NET error is:

            <faultstring>Server was unable to read request. --&gt; There is
an error in XML document (1, 324). --&gt; The specified type was not
recognized: name='string',
namespace='http://schemas.xmlsoap.org/soap/encoding/', at
&amp;lt;thestringarray xmlns=''&amp;gt;.</faultstring>

The problem is that .NET has specified xsd:string as the arrayType.  Axis
ignores this Schema stuff.  But the way the type mappings worked in 1.1, we
preferred XML Schema to soapenc types.  The new way that the
DefaultSOAPEncodingTypeMappingImpl type mapping registry is created, the
default (containing the xsd types) is a delegate to the SOAPEncoding types.
Which means that when we look up java.lang.String, we first look in the soap
encoded types and return soapenc:string.

I am planning on changing this back to Axis 1.1 behavior, which is to always
prefer the xsd types where possible.  The problem is, when I look at the 1.1
version of DefaultTypeMappingImpl, it appears that *it also* would prefer
the soapenc types when doing encoded stuff.  I am clearly missing something.

Have I mentioned how much I really hate the type mapping system in Axis? :-)

Anyway, any assistance on this would be appreciated.  Glen, you changed both
the type mapping and array stuff, so if can give me a hand, that would be
great.

--
Tom Jordahl
Macromedia Server Development

> -----Original Message-----
> From: Tom Jordahl [mailto:tomj@macromedia.com]
> Sent: Friday, October 08, 2004 12:31 PM
> To: 'axis-dev@ws.apache.org'
> Subject: Axis 1.2 RC1 release red flag
> 
> This is just a data point, but I figured I would let the group know that
> Axis 1.2 RC1 does not pass my products (ColdFusion MX) web service
> regression suite.
> 
> I hope to have fixes in the next few days, but I may not have enough
> allocated time to fix this.
> 
> Have the folks who ran JAX-RPC 1.1 successfully re-ran the suite on the
> RC1
> bits?
> 
> On the bright side, flipping on the wrapped doc/lit switch on Axis 1.2
> worked pretty well, but failed miserable on 1.1.  So we are making
> progress!
> 
> --
> Tom Jordahl
> Macromedia Server Development

Mime
View raw message