Thank you for your warm words!
But without fixed port meaning that we never test the behaviour of
ServerSocket(1000).
That's why I suggest to introduce fixed port for ServerSocket constructor
test.
My suggestion is not to discard your patch, but using your patch + fixed
port to replace current getNextPort machenism. Does it make sense? Thanks!
Why my approach does not work in this case?
For example:
void test_ServerSocketCosntructor() {
...
int port = getNextPort(); // got free port number
ServerSocket ss = new ServerSocket(port);
// tests ServerSocket opened on fixed port here
// checks if ServerSocket listens on this port etc.
...
}
Or testing ServerSocket each time on the same port number is critical?
Regards,
Mikhail
On 12/25/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
On 12/25/06, Mikhail Markov <[EMAIL PROTECTED]> wrote:
>
> > Hey Mikhail, I think I have agreed with all your words in my previous
> > letter. We've agreed to use port 0 for most network tests. Fixed port
> number
> > is required sometimes, i.e., how do you write test for
ServerSocket(int
> > port)?
> Sorry, Andrew - I did not participated in original discussion and Alexei
> in
> http://issues.apache.org/jira/browse/HARMONY-2338 said that he
> understands the final decision as we will use reserved ports numbers -
so
> I've decided to re-check once again.
>
> > We'd better test ServerSocket constructor with both legal value(not
> > only 0, but also some positive numbers), and illegal value. That's
where
> > fixed port number is used. Make sense? Thanks!
> Why not use ServerSocket(0) to just *obtain* some positive non-busy port
> number (and close it after port number obtaining) and after that test
> ServerSocket constructor with this obtained port number? In this case
> we'll
> not require any reserved ports at all.
> I've implemented this approach and attached the patch - could you please
> take a look at it?
Hi Mikhail, the patch is good! I agree that it's a good fix as always. :-)
But without fixed port meaning that we never test the behaviour of
ServerSocket(1000).
That's why I suggest to introduce fixed port for ServerSocket constructor
test.
My suggestion is not to discard your patch, but using your patch + fixed
port to replace current getNextPort machenism. Does it make sense? Thanks!
Thanks,
> Mikhail
>
>
> On 12/24/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> >
> > On 12/24/06, Mikhail Markov <[EMAIL PROTECTED]> wrote:
> > >
> > > I still don't like using fixed port numbers. Moreover, some tests
> might
> > > require several ports for testing.
> > > I did not see any objections against using 0 as a port number,
except
> > that
> > > some functionality should be tested with fixed port numbers.
> > > How about the following scheme for *finding* non-busy port:
> > > 1) invoke ServerSocket(0) constructor
> > > 2) get the port where ServerSocket opened the socket
> > > 3) close ServerSocket
> > > 4) use the stored port from 2-nd step for further testing (it could
be
> > > Socket/ServerSocket/nio tests etc.)
> > >
> > > What do you think?
> >
> >
> > Hey Mikhail, I think I have agreed with all your words in my previous
> > letter. We've agreed to use port 0 for most network tests. Fixed port
> > number
> > is required sometimes, i.e., how do you write test for
ServerSocket(int
> > port)? We'd better test ServerSocket constructor with both legal
> value(not
> > only 0, but also some positive numbers), and illegal value. That's
where
> > fixed port number is used. Make sense? Thanks!
> >
> > Thanks,
> > > Mikhail
