Further investigations seem to indicate that the SOAP server is refusing 
the first connection attempt in any given startup. If this expected? 
Since there are quite a few stop/starts happening as part of the unit 
test suite, and since things like the methods in SoapHttpClientTestCase 
only do one send per stop/start cycle, they are coming back as false.

Anyway, I've worked around around it for now by editing the class method 
"start" in SoapServerSetup, so that after the handler is started a 
temporary socket is created, connected to the handler's port (or not, as 
the case may be :), then disconnected. After that all the unit tests for 
the soap package that I was basing my code on pass! :)

Sorry I can't help out more...
S

Simon Kirk wrote:

> 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]
>>
>>
>>
>> 
>>  
>>
>
>
> Click here 
> <https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==> 
> to report this email as spam.
>
>------------------------------------------------------------------------
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060201/18e55352/attachment.htm