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 Thu, 21 Oct 2004 13:56:40 GMT

Update #3.

While I devised some code for sending XML Schema types when the WSDL
requires it, I ran in to a few problems that prevented me from checking this
code in.

1. The .NET rpc/encoded web service has schema that specifies the arrayType
attribute.  For a 2D array, it specifies an arrayType of "ArrayOfString",
but when handed XML that uses this type, what it really wants is an
arrayType of xsd:String[][].  So it does not work due to a .NET bug.

2. In working on the problem, I created code in WSDL2Java that reads the
array type from the schema and passes this along to the ArraySerializer that
is constructed in the stub.  Unfortunately, given the way serializers are
requested by the type mapping system, I had some problems with the
serializer being reused for a *different* component type.  This broke the
Axis functional tests.  I did not follow through with this to see if it was
possible to fix it, since the changes didn't address all of *my* regressions
and broke Axis in the process.

I still haven't got the full regression suite for my product to pass,
particularly with respect to .NET and the array serializer.  I am committed
to Axis 1.2, so I must resolve these regressions soon. :-)  I may have to
'fix' our type mapping system to again prefer the XML Schema types over the
soap encoded types, even when talking to an rpc/encoded service, to ensure
that we interop with .NET.

Given the changes (particularly the name mapping changes) we have made to
RC1 we need an RC2.  I will continue to work on RC2 to get it to pass my
.NET regressions and I hope to have these issues resolved in time for 1.2
final.


--
Tom Jordahl
Macromedia Server Development

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