Return-Path: 
 <axis-dev-return-30304-apmail-ws-axis-dev-archive=ws.apache.org@ws.apache.org>
Delivered-To: apmail-ws-axis-dev-archive@www.apache.org
Received: (qmail 61951 invoked from network); 21 Oct 2004 13:56:53 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 21 Oct 2004 13:56:53 -0000
Received: (qmail 28618 invoked by uid 500); 21 Oct 2004 13:56:44 -0000
Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org
Received: (qmail 28550 invoked by uid 500); 21 Oct 2004 13:56:44 -0000
Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
list-help: <mailto:axis-dev-help@ws.apache.org>
list-unsubscribe: <mailto:axis-dev-unsubscribe@ws.apache.org>
list-post: <mailto:axis-dev@ws.apache.org>
Delivered-To: mailing list axis-dev@ws.apache.org
Received: (qmail 28520 invoked by uid 99); 21 Oct 2004 13:56:43 -0000
X-ASF-Spam-Status: No, hits=0.6 required=10.0
	tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from [216.104.212.90] (HELO p01mgw01.macromedia.com)
 (216.104.212.90)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 21 Oct 2004 06:56:43 -0700
Received: from S1001EXM02.macromedia.com (s1001exm02.macromedia.com
 [10.4.48.132])
	by p01mgw01.macromedia.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id
 i9LDuZtV010063
	for <axis-dev@ws.apache.org>; Thu, 21 Oct 2004 06:56:35 -0700 (PDT)
Received: by pop-newton.allaire.com with Internet Mail Service (5.5.2657.72)
	id <SFCTVKHK>; Thu, 21 Oct 2004 09:56:40 -0400
Message-ID: <CB1FF0A474AEA84EA0206D5B05F6A4CB0AA378F9@pop-newton.allaire.com>
From: Tom Jordahl <tomj@macromedia.com>
To: "'axis-dev@ws.apache.org'" <axis-dev@ws.apache.org>
Subject: RE: Axis 1.2 RC1 release red flag
Date: Thu, 21 Oct 2004 09:56:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


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