commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Adding TERMINAL-TYPE option to TelnetClient
Date Sun, 30 Mar 2003 18:01:27 GMT

thanx for taking the time to review and comment the patch.
In the following couple fo days I will try to fix some of the problems
you have seen in the code.

> * TelnetClientExample3 uses the TestTeslnetServer and that class is in
>   the src/test tree.  I can't build with maven when this is the case.
>   Maybe we could use the spy stuff on an existing server instead of
>   the test server or just provide test cases instead of examples (
>   this is something I've been thinking about for all the *examples*,
>   or converting them to documentation or something ).

Maybe converting the examples to documentation is the best thing to do.
Alternatively, I could modify the TelnetClientExample3 to output the spy on
a file instead of waiting a second telnet connection and spying the primary
connection on the second connection as it does at the moment.
What do you think about?
> * Some of the tests use System.out/err and do alot in the setUp()
>   methods ( TelnetClientTest ).  Maybe restructuring some of these
>   test may be in order.

what should the test do in case an I/O exception occurs?
(throw the exception, catch it silently...?) I mean, how is it normally
managed an error condition in the test?
I'll try to restructure TelnetClientTest not to do so much in the setUp().
> * Possibly defining an abstract test case for the option handlers and
>   have most tests done there.  Then each descedendin test case just
>   creates the fixtures that will be tested. ( see the parser abstract
>   test case ).

Great idea! I'll certainly do that.

> * The code style conventions should be followed. ( minor )
Could you be more specific? I tried to keep up to the standard coding style
used in commons net, which is fairly low :-). I'll try to add javadoc comments
to each new class and method, but I don't have the time to fully comment the

> * Some code doesn't have licenses on them. ( minor )

I'll add

> The functional tests are nice to see in there, but I suppose we'll
> need to find out a way to skip them at compile time for users who
> build but don't have access to get to the internet.

Two solutions for TelnetClientFunctionalTest:

1) we could try to skip it if you don't have connection to the internet,
but in this case it would be a test that is always succeeding!

2) I have a handy & powerful TCP util that could help us to do a nicer job: 
TCPSpy, which is a sort of proxy that can be used to record characters going
back&forth on a TCP connection. Later on you can use TCPSpy to playback
characters as if you were connected to the real server, using the recorded session.
TCPSpy could be included in or and used during the test in case the internet
connection fails.
I send you the source code of TCPSpy so you can have a look at it and tell me
what do you think about this option.
To use TCPSpy:

java TCPSpy <proxy-port> <remote-host> <remote-port> 
starts TCPSpy in record mode. You connect to the port <proxy-port> on the
machine running TCPSpy and it will forward the connection to
the <remote-host>:<remote-port> and record the sessions on a file

java TCPSpy -playback [-exact] <proxy-port> <file>
plays back a recorded session. You connect to <proxy-port> of the machine on
which TCPSpy is running, and it plays back the session. Playback is synchronized on
characters you type on the new connection (if the client sent two chars before
receiving a line from the server in the original session, TCPSpy will wait for two
chars before going ahead with the playback of the same session when in
playback mode) also, playback mode will time the server chars exactly the same
way the original server did in the recorded session.

TCPSpy can also be used inside programs, by using TCPSpy class.
I enclose TCPSpy (temporarily included in and an
example of how TelnetClientFunctionalTest could be modified, and a file which
is a session recorded on the original weather service
You can try the playback by yourself by launching:

TCPSpy -playback 3000 weather.log
connecting to port 3000 and acting as the client did in the original session:
- wait for the welcome screen and prompt
- press enter
- wait for prompt and enter "LAX"
- enter X

Maybe the only problem could be that if we want to include TCPSpy in commons
net we should write some tests for it too, which is a pretty complex task (one for
which I won't have the time in the next future)

Well Jeffrey,
Thanks again for comments and please, give me some more hint on how to
go on!


View raw message