Sorry for the reticence today, Tom and I have been mired in debugging all day. :(

I would prefer that we not move too far towards having all the samples + tests be 
based on generation from WSDL.  When we originally changed the code of the echo sample 
to be generated and then checked in, I was OK with that, but I think I'd rather it 
stay that way than be generated.  So I'm -0.

Also, echoMap is implemented by several other vendors and should definitely stay in 
there, IMHO.  Keeping them in there keeps the interop results up to date and tests 
good functionality.

--Glen

> -----Original Message-----
> From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 05, 2002 3:36 PM
> To: [EMAIL PROTECTED]
> Cc: Sam Ruby
> Subject: Proposal to change EchoTest (interop test) to be gen'd from
> wsdl
> 
> 
> The samples.echo service and artifacts are hand-crafted and 
> committed code.
> Thus the stubs and artifacts are frequently out of date with 
> the emitters
> and runtime.
> 
> I propose changing the sample so that the service, stubs and beans are
> generated
> directly from the WSDL supplied by WhiteMesa (actually local 
> copies of the
> WSDLs with
> our service stanzas added).
> 
> I am implementing these changes in my sandbox, and I have 
> come across 2
> "problems":
> 
> 1) The TestClient has two options which affect the setting of the
> soapAction.  The
> emitted stub is hard-coded to use the soapAction specified in 
> the wsdl (a
> good thing).
> So I propose eliminating these two options from 
> TestClient...they are not
> used in our
> scripts anyway.
> 
> 2) The current code has echoMap and echoMapArray operations.  
> Neither of
> these
> are present in the white mesa wsdl document (and almost all 
> of the remote
> services
> fail to implement these operations).  I propose getting rid of these
> operations.  If someone
> thinks they are useful, we should move them to another test.
> 
> Any comments ?
> 
> Could I get some +1's.  Thanks,
> 
> Rich Scheuerle
> XML & Web Services Development
> 512-838-5115  (IBM TL 678-5115)
> 

Reply via email to