harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: Running org.apache.harmony.tests.java.nio.channels tests (was: Re: classlib test suite status emails?)
Date Wed, 12 Apr 2006 11:38:34 GMT
Mark Hindess wrote:
> Why must we testing the hostname?  Why not test the actual address,
> 127.0.0.1?  That should be much more reliable and less platform
> dependent.
>
> Regards,
>  Mark.
>   

Sounds good to me.

Paulex, in your view would it compromise the worth of this test if 
instead of doing :

--> InetSocketAddress returnAddr = (InetSocketAddress) 
this.channel1.receive(buf);
--> assertEquals(returnAddr.getHostName(), LOCALHOST_NAME);

..the test did *something* like below ?

--> InetSocketAddress returnAddr = (InetSocketAddress) 
this.channel1.receive(buf);
--> InetAddress addr = returnAddr.getAddress();
--> assertEquals("127.0.0.1", addr.getHostAddress());


Best regards,
George


>
> On 4/12/06, LvJimmy´╝îJing <firepure@gmail.com> wrote:
>   
>> Hi:
>>
>> 2006/4/12, Stepan Mishura <stepan.mishura@gmail.com>:
>>     
>>> On 4/11/06, Paulex Yang wrote:
>>>       
>>>> [SNIP]
>>>>         
>>>>> I've run tests on Linux. They fail on the same assertion:
>>>>>     [junit] Testcase: testReceiveSend_Block_Normal(
>>>>> org.apache.harmony.tests.java.nio.channels.DatagramChannelTest ):
>>>>>           
>>>> FAILED
>>>>         
>>>>>     [junit] expected:<...> but was:<....localdomain>
>>>>>     [junit] junit.framework.ComparisonFailure: expected:<...> but
>>>>> was:<....localdomain>
>>>>>     [junit]     at
>>>>>
>>>>>           
>>> org.apache.harmony.tests.java.nio.channels.DatagramChannelTest.receiveByChannel
>>>       
>>>>> (DatagramChannelTest.java:1681)
>>>>>     [junit]     at
>>>>>
>>>>>           
>>> org.apache.harmony.tests.java.nio.channels.DatagramChannelTest.testReceiveSend_Block_Normal
>>>       
>>>>> (DatagramChannelTest.java:1419)
>>>>>     [junit]     at java.lang.reflect.AccessibleObject.invokeV(
>>>>> AccessibleObject.java:205)
>>>>>
>>>>>           
>>>> Stepan,
>>>>
>>>> Thank you for the information.
>>>>         
>>>>> As far as JUnit didn't print what result was expected to get I
>>>>>           
>>> inserted
>>>       
>>>>> printing to the test and got the following:
>>>>> Expected host: localhost.localdomain
>>>>> Recieved host:  localhost
>>>>>
>>>>> Why do you expect that on Linux "localhost.localdomain" should be
>>>>>           
>>>> returned?
>>>>         
>>>> Well,  that is because both RI/Harmony return this value on my test
>>>> machines(Redhat ES 3, Redhat 9 and latest stable Debian),  and I didn't
>>>> expect this value is dependent on configuration(or Linux distribution?
>>>> ), but as your test result shows, it probably does! So would you tell me
>>>> your linux distro version and configuration( for example, what it looks
>>>> like of the item on localhost in /etc/hosts)? so that I can check if
>>>> this constant value(localhost.localdomain) is platform dependent.
>>>>         
>>> Hi Paulex,
>>>
>>> I run tests on SUSE LINUX ES 9, file /etc/hosts contains the next entry:
>>> 127.0.0.1       localhost
>>>       
>>
>>     Currently I have a linux workstation, file /porc/version show it is
>> "Linux version 2.4.21-15.ELsmp (bhcompile@bugs.build.redhat.com) (gcc
>> version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)) #1 SMP Thu Apr 22 00:18:24
>> EDT 2004", and its /etc/hosts tells:
>>   127.0.0.1       localhost.localdomain           localhost
>> google tells me that Debian3.1 and redhat 8.0 also contain this field
>> defaultly.
>> Shall we call it as platform-release-dependency problems? :)
>>
>> The are no entries with " localhost.localdomain". Today also I run these
>>     
>>> tests on WinXP - all DatagramChannelTest passed but SocketChannelTest
>>> (testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData) failed with the
>>> following diagnostics:
>>>
>>> expected:<24820> but was:<65536>
>>>       
>> junit.framework.AssertionFailedError: expected:<24820> but was:<65536>
at
>>     
>>> org.apache.harmony.tests.java.nio.channels.SocketChannelTest.testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData
>>> (SocketChannelTest.java :2579) at
>>> java.lang.reflect.AccessibleObject.invokeV(
>>> AccessibleObject.java:205)
>>>
>>> Is this enough for you to identify a problem? Please let me know if you
>>> need
>>> more info.
>>>
>>> Thanks,
>>> Stepan.
>>>
>>> And I'll also look more inside to see if there can be other cause except
>>>       
>>>> for the possible platform difference.
>>>>         
>>>>> Thanks,
>>>>> Stepan.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> And before everything's OK, I'm fine if you choose to add
>>>>>> DatagramChannelTest into exclude list, by adding it to Ln.94 of
>>>>>> modules/nio/make/common/build.xml, just as ServerSocketChannelTest.
>>>>>>
>>>>>> Sorry for the inconvenience caused.
>>>>>>
>>>>>>             
>>>>>>> And there are new 15 test failures.  So now if I'll make a code
>>>>>>>               
>>> update
>>>       
>>>>>> or a
>>>>>>
>>>>>>             
>>>>>>> bug fix how I can be 100% sure that I don't do any regression?
>>>>>>>
>>>>>>> Currently if a commit breaks the Harmony classlib build a
>>>>>>>               
>>> notification
>>>       
>>>>>> with
>>>>>>
>>>>>>             
>>>>>>> subject: "[continuum] BUILD FAILURE: Classlib/linux.ia32" will
be
>>>>>>>               
>>> send
>>>       
>>>>>> to
>>>>>>
>>>>>>             
>>>>>>> harmony-commits mailing list. Is it possible to have the same
for
>>>>>>>               
>>>> tests?
>>>>         
>>>>>> I
>>>>>>
>>>>>>             
>>>>>>> mean that after completing automatic build the existing classlib
>>>>>>>               
>>> tests
>>>       
>>>>>> suite
>>>>>>
>>>>>>             
>>>>>>> should be run. If there are failing tests then a report notification
>>>>>>>
>>>>>>>               
>>>>>> with
>>>>>>
>>>>>>             
>>>>>>> corresponding subject will be send.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Stepan Mishura
>>>>>>> Intel Middleware Products Division
>>>>>>>
>>>>>>>               
>>> ---------------------------------------------------------------------
>>>       
>>>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>>>> For additional commands, e-mail:
>>>>>>>               
>>> harmony-dev-help@incubator.apache.org
>>>       
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>       
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>>
>>     
>
>
> --
> Mark Hindess <mark.hindess@googlemail.com>
> IBM Java Technology Centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>   


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message