Hi,

I've tested SoapCore 0.8 on Windows VM (Squeak-Win32-3.7.1-VM.zip) and the
image is Squeak 3.8-6665.

SoapHttpClientTestCase >> #testSimpleEnvelopeSend runs perfectly well.

So, maybe it's a VM issue. I'll test the same test case in Linux VM.
So, just wait for
a moment.

2006/2/1, Simon Kirk <Simon.Kirk at pinesoft.co.uk>:
>  Hi Masashi.
>
>  No, this is on Squeak 3.8 (Smalltalk vmVersion returns 'Squeak3.8gamma of
> ''24 November 2004'' [latest update: #6548]'), SUnit version 3.1.22,
> SoapCore 0.8.
>
>  It certainly seems like some kind of threading/timing issue - but things
> are very strange. For a bit more detail: If I put a break point in the
> method "testSimpleEnvelopeSend" in SoapHttpClientTestCase thus:
>
>  testSimpleEnvelopeSend
>
>      | curPort retXML envelope body method |
>      SoapServerSetup startOnly: #(http).
>      SoapServiceHandler default add: self simpleService.
>      curPort := SoapSetting defaultPortAt: #http.
>      self halt. ' <--------- Here's the break point
>      retXML := (SoapHttpClient url: 'http://localhost:', curPort
> printString, '/' ) send: self simpleEnvelope.
>      envelope := SoapEnvelopeBuilder new buildSoapEnvelopeFromXmlString:
> retXML.
>      [snip]
>
>  Then if I wait a few seconds, the proceed, that test send works. If I press
> process quickly, then it doesn't work.
>
>  So it looks like the section where the simpleService  is added to the
> server isn't being given enough time to establish a listening port. Does
> that look correct?
>
>  Cheers,
>  Simon
>
>
>  Masashi UMEZAWA wrote:
>  Hi,
>
> Do you use Squeak 3.9a? If so, I think it is partly because of the new
> TestRunner, which seems to be running multi-threaded now.
>
> I will upgrade my test cases for the next release.
>
> Cheers,
>
> 2006/1/31, Simon Kirk <Simon.Kirk at pinesoft.co.uk>:
>
>
>  Hello all. I'm playing with the soap toolkit from SqueakMap, but
> something seems to be wrong: If I run some SUnit tests (specifically
> client ones - such as SoapHttpClientTestCase, or SoapCallTestCase) they
> are failing, saying they cannot connect to the server (localhost, port
> 8823). However, if I step through the tests via debugging, right into
> the point where the call is made to the server, the call appears to work
> fine (a connection is made, the expected return is received).
>
> What could be wrong here? It's almost like with the automated tests the
> server is dying before the tests are ever connecting.
>
> Cheers,
> S
>
>
> This message has been scanned for viruses by BlackSpider MailControl -
> www.blackspider.com
>
>  --
> [:masashi | ^umezawa]
>

--
[:masashi | ^umezawa]