axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <bu...@us.ibm.com>
Subject RE: WSDL tests
Date Thu, 29 Nov 2001 18:48:01 GMT
Oops!  You're right.  I guess it is just my 3 that actually use the
generated impl, then.

Russell Butek
butek@us.ibm.com


Tom Jordahl <tomj@macromedia.com> on 11/29/2001 11:27:02 AM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  RE: WSDL tests




Do the interop tests actually use the server side?  I didn't realize that.
I thought they talked to the interop servers at whitemesa...

--
Tom Jordahl


-----Original Message-----
From: Russell Butek [mailto:butek@us.ibm.com]
Sent: Thursday, November 29, 2001 12:22 PM
To: axis-dev@xml.apache.org
Subject: RE: WSDL tests


These are the tests that use the generated impl:
2 import tests
a clash test
and a whole bunch of wsdl files that come from elsewhere:
    "http://www.xmethods.net/tmodels/InteropTest.wsdl"
    "http://www.whitemesa.com/interop/InteropTest.wsdl"
    "http://www.whitemesa.com/interop/InteropTestB.wsdl"
    "http://www.whitemesa.net/wsdl/std/echoheadersvc.wsdl"
    "http://mssoapinterop.org/stk/InteropB.wsdl"
    "http://mssoapinterop.org/stk/InteropC.wsdl"
    "http://www.uddi.org/wsdl/inquire_v1.wsdl"
    "http://www.uddi.org/wsdl/publish_v1.wsdl"
    and there are even more that are commented out because they fail at the
moment.

Russell Butek
butek@us.ibm.com


Tom Jordahl <tomj@macromedia.com> on 11/29/2001 10:44:14 AM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  RE: WSDL tests




In many (most?) of the tests (the couple that I wrote at least) we
substitute a real implementation in for the one generated by the emitter.

How many of the WSDL tests use the default server implementation?

--
Tom Jordahl
Macromedia Server Development



-----Original Message-----
From: Russell Butek [mailto:butek@us.ibm.com]
Sent: Thursday, November 29, 2001 8:29 AM
To: axis-dev@xml.apache.org
Subject: Re: JavaStubWriter:
Utils.capitalizeFirstChar(qn.getLocalPart()?


Interesting problem (grumble grumble).  Actually, it's two problems.

1.  There's a bug in JavaStubWriter.  I've got it on my todo list (though
that doesn't mean no-one else could tackle it - hint hint).
2.  Are our tests doing the right thing?  Our tests use the generated
impl's.  These impls were originally meant to be nothing more than
templates to help users write them.  They originally threw NoImplement.  We
changed them to return valid values so we could use them in our tests.  The
good thing about this is that our WSDL tests are easy to write and we
essentially test the generation of the impls every time we run the tests.
The bad thing is those valid values are rather meaningless.  So what do we
do?  I propose keeping the existing Wsdl2java tests as they are since
they're meant to test WSDL generation.  But we may need a version of some
of these tests that are more fully baked so that we catch runtime problems
like this one.

Russell Butek
butek@us.ibm.com


Sam Ruby/Raleigh/IBM@IBMUS on 11/28/2001 09:05:20 PM

Please respond to axis-dev@xml.apache.org
To:   axis-dev@xml.apache.org
cc:
Subject:  JavaStubWriter: Utils.capitalizeFirstChar(qn.getLocalPart()?



In order to improve interoperability, I was looking into distinguishing
between void returns and returns of values that happened to be null on this
call.  Unit tests all passed, but Test
test.clash.AirportWeather_ServiceTestCase failed.  These tests were run
with null results previously, and so now would actually attempt to
serialize results as xsi:nil="true".

 The error I got was  "Deserializing parameter 'getLocationResult':  could
not find deserializer for type http://www.w3.org/2001/XMLSchema:String

The actual localPart in the qname is supposed to be string (all lowercase).

Looking at JavaStubWriter, I see several instances of:

            String typeString = "new org.apache.axis.encoding.XMLType( new
javax.xml.rpc.namespace.QName(\"" + qn.getNamespaceURI() + "\", \"" +
                    Utils.capitalizeFirstChar(qn.getLocalPart()) + "\"))";

It is my guess that any time you want to deal with the QName as a QName you
want to do so ASIS - at least for BaseJavaTypes.

This failure was only masked by the choice to use nulls in the test, and
the way nulls are currently handled.  Any other values would likely fail.

- Sam Ruby






Mime
View raw message