Hi Jeffrey,
I made a bit of rework on the telnet client patch in order to
(partially) solve the problems you saw.
- The Apache license has been added to all sources
- I tried to improve compliance with the coding style
standards (I'm still not able to run maven, so I can't see
the reports...)
-
On Sun, 30 Mar 2003 20:01:27 +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] said:
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
Bruno,
I just finally had some time to look at your patches and I am
attempting to look at the tests and learn about the
implementation/functionality. A couple of initial observations:
* TelnetClientExample3 uses the TestTeslnetServer and that class is in
the src/test tree. I can't build
Hi,
I added yet another functionality to TelnetClient, which is very handy to debug:
You can spy what's going on in the TelnetClient session by registering to it
an OutputStream. TelnetClient will copy all the session activity on the registered
outputstream.
- TelnetClient: added two new methods
Jeffrey,
I had some problem while running the JUnit tests for the TelnetClient
patch on an HP-UX platform (trying to stress test the test cases).
Th problem was due to a lack of syncronization between TelnetClient
and the mini-server scaffold thread.
So I had to change something to solve the
Will do, I'll let you know when I take a look.
Thanks for all your work!
On Thu, 20 Mar 2003 16:24:27 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] said:
Jeffrey, I had some problem while running the JUnit tests for the
TelnetClient patch on an HP-UX platform (trying to stress test the
test
Jeffrey,
In the enclosed file you will find some
JUnit test cases for the TelnetClient patch.
The test cases support the last version of the patch
(the one I sent on march 17th). I won't write test
cases for the previous alternative version unless we
decide that we want to apply that version of
Hi,
last thursaday 3 13th I submitted a patch for an extended version of commons net's
TelnetClient containing new functionalities.
The support for an external option handler was through the TelnetOptionHAndler
interface. The same object was used to handle all the options, with the result of a
I have looked at your one of your last submission, and just haven't
had time to look in detail, sorry. I'll try to look today/tomorrow
though. One other minor point, maybe in this latest patch you have,
but could you try providing some test cases or are you using the
Telnet example as a sort of
I have looked at your one of your last submission, and just haven't
had time to look in detail, sorry. I'll try to look today/tomorrow
though. One other minor point, maybe in this latest patch you have,
but could you try providing some test cases or are you using the
Telnet example as a sort of
On Mon, 17 Mar 2003 16:37:17 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] said:
I think that the simplest way is to use the Telnet examples as a
test for the new funtionality. I'll review the examples to see if
they cover all the new stuff. I have been thinking about providing
test cases: the
I agree that testing at the protocol level would be needed and also a
functional test against some existing servers. Both types of tests
are going to be useful. Currently there are no tests, only some
examples. This is an area where commons-net really needs some polish.
It may be difficult to
On Mon, 17 Mar 2003 17:58:43 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] said:
- I'll try to have ready a simple server that is configurable enough
for setting up different test cases at the protocol level. It could
be reused for testing all the TelnetClient protocol compliance when
someone
Hi to all,
In the last days I already submitted a patch for an extended version
of TelnetClient supporting TERMINAL-TYPE and a second patch
containing the same + a bug fix for a previous problem of TelnetClient.
This new patch contains all the preceeding changes + some new
functionality that has
You forgot to include a patch :)
I include a zip file with the sources for the TERMINAL-TYPE patch.
I am really a newbie in contributing to jakarta, so i'm sorry if this is
not the right procedure for submitting patches.
Also, I think that the support for subnegotiating options can be reused
BUGFIX: The old TelnetClient did not clean the arrays used for option processing
for each connection (as in the original class no option was accepted, the bug was there
but it did not have the chance to come out)
In the case that the same TelnetClient instance is used for more than one time, this
Hi:
In order to fix a problem while connecting to an OpenVMS server (delay of the OpenVMS
login process when the terminal type is unknown) I added support of the TERMINAL-TYPE
telnet option, RFC 1091 to the TelnetClient class of the Commons Net library
In message [EMAIL PROTECTED], =?iso-8859-1?Q
[EMAIL PROTECTED] writes:
I think this functionality could potentially be interesting for other users of
the library, so I would like to propose that the updated sources be included
You forgot to include a patch :)
I think it goes without saying that
18 matches
Mail list logo
