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 Tue, 12 Oct 2004 17:49:47 GMT

Update #2

I have resolved all of my issues except for the one detailed below.  Axis
1.1 preferred XML Schema types for arrays instead of the SOAP encoded types.
This worked to our advantage when talking to a .NET rpc/encoded service,
which specifies in schema that it wants xsd types.  Trying to restore that
behavior is "challenging". :-(

Unfortunately, changing the ordering of our default TypeMapping seems to
break some functional tests, in particular we seem to have some issues with
returning plain (int) types instead of wrapped types (Integer), probably due
to the fact that SOAP encoded types can be null.

I am still looking at it.

--
Tom Jordahl
Macromedia Server Development

> -----Original Message-----
> From: Tom Jordahl [mailto:tomj@macromedia.com]
> Sent: Monday, October 11, 2004 10:30 AM
> To: 'axis-dev@ws.apache.org'
> Subject: RE: Axis 1.2 RC1 release red flag
> 
> 
> 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