Re: Adding TERMINAL-TYPE option to TelnetClient
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...) - A new abstract class for test of option handlers has been added all the test cases for option handlers derive from that class - No System.out/err usage in the test cases - Some restructuring of the test cases not to do so much in setUp/tearDown - TelnetClientExample3 now sends the spy on a file (spy.log) No changes have been made to the implementation/functionality. I'm looking forward to more info from you, Bruno commons-net-openoption-patch5.ZIP Description: Zip compressed data commons-net-openoption-patch5-test.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 the primary connection on the second connection as it does at the moment. What do you think about? Writing to a file sounds reasonable for the example. If you want to add documentation that would also be great. Maybe a how-to or faq of sorts. You could just provide xdocs or use the apache wiki. 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(). The general convention when there is an error condition that the test is not testing for is to let the exceptions fly. Junit will ultimately catch all the exceptions and report it as an *error* and not a *failure*. Generally I don't catch exceptions in my test cases unless I'm explicitly testing for the throwing of an exception. * 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 code... http://jakarta.apache.org/commons/net/code-standards.html I know there are violations in the current code base, the checkstyle report shows that. But for new stuff we should try to stick to the above standard when possible and verify with checkstyle. 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! I think that the running of the fuctional tests could require a connection to a real server over a network. I just think that the build shouldn't depend on the functional tests. This is something that I've been wanting to add to Maven for some time. An additional goal for functional tests so they can be removed from the normal *unit* test run that happens at each build. I was thinking of just a different goal, like maven test:ftests or something. For now I suppose we could exclude the tests that require the net and just provide directions to run single tests with maven to run those that require the net. I'll still take a look at the tcpspy stuff as I get time. Thanks again. jb -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 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 ). * 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. * 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 ). * The code style conventions should be followed. ( minor ) * Some code doesn't have licenses on them. ( minor ) 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. Thanks again for your work and I apologize for taking so long to look at it. I've just scratched the surface of what you've written! Hopefully more info to come as I have time. Thanks for your patientce. jb On Mon, 24 Mar 2003 11:43:08 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] said: 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 (registerSpyStream(), stopSpyStream()) - Telnet: Added new methods to manage the spy stream - TelneInputStream: calls a Telnet's method to copy the received chars on the output stream - TelnetClientExample3: It is a new example showing the use of registerSpyStream() an stopSpyStream(). It opens a telnet connection to a server, then listen to port . Just connect to port with an external telnet, then type SPY on the TelnetClientExample3 terminal and you will see all the TelnetClient traffic copied on the telnet connection to port . UNSPY will stop spying the connection. I enclose another patch which includes all the preceeding + the new spy stream functionality (sources + JUnit tests). Again, sorry for sending so many versions of this patch, I'm just adding the functions I need one at a time when I have got some free time to do that. If you ave some comments or need some explanation, please contact me. Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 (registerSpyStream(), stopSpyStream()) - Telnet: Added new methods to manage the spy stream - TelneInputStream: calls a Telnet's method to copy the received chars on the output stream - TelnetClientExample3: It is a new example showing the use of registerSpyStream() an stopSpyStream(). It opens a telnet connection to a server, then listen to port . Just connect to port with an external telnet, then type SPY on the TelnetClientExample3 terminal and you will see all the TelnetClient traffic copied on the telnet connection to port . UNSPY will stop spying the connection. I enclose another patch which includes all the preceeding + the new spy stream functionality (sources + JUnit tests). Again, sorry for sending so many versions of this patch, I'm just adding the functions I need one at a time when I have got some free time to do that. If you ave some comments or need some explanation, please contact me. Bruno commons-net-openoption-patch4.ZIP Description: Zip compressed data commons-net-openoption-patch4-test.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 problem (new Reader class that allows the scaffold server reading and sending responses in a separate thread. I enclose the new version of the test suite. Please, let me know if you have any problems while running the tests. Bye, Bruno commons-net-openoption-patch3-test.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 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 problem (new Reader class that allows the scaffold server reading and sending responses in a separate thread. I enclose the new version of the test suite. Please, let me know if you have any problems while running the tests. Bye, Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 the patch. You'll find three groups of test cases: - Unit tests. These are for the new classes, without hitting the network (InvalidTelnetOptionExceptionTest, SimpleOptionHandlerTest, SuppressGAOptionHandlerTest, TerminalTypeOptionHandlerTest, EchoOptionHandlerTest. - Protocol compliance tests. Finally, I implemented a simple test server (TelnetTestSimpleServer) that is used to do the testing at the protocol level. It is a very simple server that listens for connections in an independent thread and can be controlled by the outside for sending/receiving bytes. By the time, this test hasn't got 100% coverage of telnet protocol compliance. It covers to some extent option negotiation and AYT processing. (TelnetClientTest) - Functional test. It is a small functional test in which TelnetClient is used to look for Los Angeles weather forecast at rainmaker.wunderground.com (TelnetClientFuntionalTest). All the tests are JUnit, so you should be able to automatically execute them, but they have some requirements: - For the protocol compliance test, the simple server listens on ports , 3334, 3335. Make sure that these ports are free. - For the functional test, make sure that you can reach the weather service rainmaker.wunderground.com. A major issue for this last test is that it expects the serve sends some fixed strings. If in the future rainmaker.wunderground.com is changed (for example, more menus are added or prompts are changed) the functional test won't be working anymore. Any idea for a more robust funtional test will be greatly appreciated!! Law of testing: No matter how many tests you have done before, any execution of a test suite comes out with some bug. This case is no exception: Executing the test cases I found two bugs: - A bug in the option negotiation logic which was already there in the original telnet client (In case TC sends a DO, remote party refuses it sending a WONT, TC didn't acknowledge with a DONT. Simmetrically when TC sends a WILL, remote sends DONT TC didn't acknoledge with a WONT). - A bug in the new getLocalOptionState() and getRemoteOptionState() API methods. The bugs have been fixed by modifying Telnet.java and TelnetClient.java I enclose source code for the patch (all the sources are included, patch + the two bug fixes) Bye, Bruno commons-net-openoption-patch3.zip Description: Zip compressed data commons-net-openoption-patch3-test.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 somehow reduced reusability of the option handlers. To improve reusability and cleanness of the interface I worked out a second patch in which the support for external option handlers is implemented in a different way: - An abstract base class for option handlers has been defined. - The user builds the actual option handler class for each option by extending the base class. the option hadler class takes care of whether to activate the option or not (local and remote side) and manages the subnegotiation - for each option the user registers a different option handler to TelnetClient This new patch is an alternative to the patch I sent on 3 13th, in that it doesn't provide new functionality, rather the same functionality is offered through a different API. I suggest that you take a look at both alternatives, even if I think that this new alternative goes a bit beyond in providing a reusable way of dealing with option handling. This new patch also includes a correction to the option handling mechanism (a flush() of the output stream has been added after sending option negotiation sequences, to ensure that negotiation occurs ASAP). A brief description of the new patch: - TelnetOptionHandler is an abstract base class for option handling. User extends this class specifying how to do subnegotiation for each of the options he wants to support. - EchoOptionHandler, TerminalTypeOptionHandler, SuppressGAOptionHandler, SimpleOptionHandler are a library of already provided option handlers. SimpleOptionHandler allows managing all options that don't require subnegotiation. - TelnetInputStream has been modifies to handle option subnegotiation and AYT response checking. - Telnet has been modified by adding new constructors, for handling TERMINAL-TYPE and for driving the control of option negotiation through the user provided TelnetOptionHandler instances. Also, methods for adding/removing the TelnetOptionHandler instances have been added. - TelnetClient has been modified by adding new constructors and interface methods. - TelnetClientExample1 is an example terminal that uses external TelnetOptionHandler instances and demonstrates use of sendAYT(), getLocalOptionState(), getRemoteOptionState(), SimpleOptionHandler, addOptionHAndler(), removeOptionHandler(). - TelnetClientExample2 is the same example terminal without use of the external option handler but using the built in TERMINAL-TYPE support. I know that I'm providing too much patches for the same functionality and this can be confusing. Sorry for that! Again, I think that the best is evaluating the last two patches (I prefer the second one). Any comment or suggestion will be welcome. Bruno commons-net-openoption-patch2.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 smoke test for the changes? Thanks again for your contributions! -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 smoke test for the changes? Hi Jeffrey, 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 problem is we should have a telnet server with a controlled behaviour (one for which we can set option managing properties) to define true test cases for the new functionalities. As we are going to test how TelnetClient implements the protocol (option negotiation and subnegotiation) we should have the possibility to set up the test cases (and look at the result) at the protocol level. I tried to find the original test suites for commons net (because the original test for TelnetClient should have the same problem) but couldn't find it. Can you please send me a link to it? The idea could be modifying it for the new stuff... Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 problem is we should have a telnet server with a controlled behaviour (one for which we can set option managing properties) to define true test cases for the new functionalities. As we are going to test how TelnetClient implements the protocol (option negotiation and subnegotiation) we should have the possibility to set up the test cases (and look at the result) at the protocol level. I tried to find the original test suites for commons net (because the original test for TelnetClient should have the same problem) but couldn't find it. Can you please send me a link to it? The idea could be modifying it for the new stuff... Bruno, 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 write *unit tests* for the existing code, but functional tests might have to do instead. But for new code ( especially new classes ) we could start with unit tests that do not require external systems. It is a difficult task to start out with, but one I think we need to start talking about at least. So any idea on getting a test harness for functional tests ( fit.c2.com / fitnesse.org are what I'm currently using at work and seems to work well ) and/or staring with some small unit tests would be beneficial. Maven is setup to fire junit based tests nicely and we have some unit tests for the line parsers for the ftp code already. Thanks. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 write *unit tests* for the existing code, but functional tests might have to do instead. But for new code ( especially new classes ) we could start with unit tests that do not require external systems. It is a difficult task to start out with, but one I think we need to start talking about at least. So any idea on getting a test harness for functional tests ( fit.c2.com / fitnesse.org are what I'm currently using at work and seems to work well ) and/or staring with some small unit tests would be beneficial. Maven is setup to fire junit based tests nicely and we have some unit tests for the line parsers for the ftp code already. Jeffrey, Thanks for the info. If you agree we could go on this way: - 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 has the time to accomplish the task of analyizing the part of telnet protocol implemented by it and defining test cases for it. But... how do we ensure that the tester server we use doesn't have some problem affecting the test results?. I'll try to keep it as simple at possible, and it should be strongly reviewed to ensure that it is (almost) bug free. - For the unit testing, I think that it's possible only for classes whose behaviour does not depend drammatically on the presence and behaviour of another party on a network (unless we are able to use the same tester protocol server of the above point for unit-test the network classes). So I think that we could do, by the moment, the unit test of the new classes (which by themselves don't require a network partner to test, as they aren't accessing the network). I'll look at Maven for these tests. - We can use TelnetExample1 and TelnetExample2 with some existing server on the net (rainmaker.wunderground.com ?) to do the functional testing. If you agree, I'll try to come out with the tester server in a couple of day... still busy at work.. :-( Also, I'll try to see how to do unit testing on TelnetOptionHandler, its derived classes and InvalidTelnetOptionException by using Maven (which I haven't seen yet). Regarding the functional test, I had a look at the examples, it should be enough. The examples are simple terminals that allows you to connect to a server and, besides providing access to the server, accept some commands that axercise the new APIs. Have a look at them and tell me what do you think about, if you have the time for it. Another point: how should we document the test procedure? For example, it is likely that the functional tests should be run by a person which will follow a test procedure looking for some desired test results. How do we document this? Bye, Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 has the time to accomplish the task of analyizing the part of telnet protocol implemented by it and defining test cases for it. But... how do we ensure that the tester server we use doesn't have some problem affecting the test results?. I'll try to keep it as simple at possible, and it should be strongly reviewed to ensure that it is (almost) bug free. This sounds good. Are you thinking of a junit TestCase that unit tests would specialize or a set of mocks/stubs that test cases would use as fixtures to setup different states? I haven't dug into the telnet code much, but it seems that we really want to test the state machine given different protocol inputs? There was an article about testing network level stuff, I think I referenced it here on this list once, I'll see if I can find it. ( Unless someone remembers for me ) - For the unit testing, I think that it's possible only for classes whose behaviour does not depend drammatically on the presence and behaviour of another party on a network (unless we are able to use the same tester protocol server of the above point for unit-test the network classes). So I think that we could do, by the moment, the unit test of the new classes (which by themselves don't require a network partner to test, as r these tests. This sounds like what we want to achive above with the protocol tests also. I'm thinking we wouldn't need to hit the wire at all for these types of tests. - We can use TelnetExample1 and TelnetExample2 with some existing server on the net (rainmaker.wunderground.com ?) to do the functional testing. Agreed. If you agree, I'll try to come out with the tester server in a couple of day... still busy at work.. :-( Also, I'll try to see how to do unit testing on TelnetOptionHandler, its derived classes and InvalidTelnetOptionException by using Maven (which I haven't seen yet). Regarding the functional test, I had a look at the examples, it should be enough. The examples are simple terminals that allows you to connect to a server and, besides providing access to the server, accept some commands that axercise the new APIs. Have a look at them and tell me what do you think about, if you have the time for it. I understand about being busy ;) Another point: how should we document the test procedure? For example, it is likely that the functional tests should be run by a person which will follow a test procedure looking for some desired test results. How do we document this? We should try to automate it. We don't want to have manual tests if we can help it. If we have a lengthy setup of the testing environment or need some kind of definitions for the functional tests, we could use the apache wiki or add a document to the commons web site. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 been added to TelnetClient. Please, if you didn't already look at the preceeding patches, ignore them and take a look at this new version. Functionalities: - built-in support for TERMINAL-TYPE - Support for an external, user provided, option handler (the option handler is defined by implementing in a user class the new TelnetOptionHandler interface. A SimpleTelnetOptionHandler class is already provided. - Synchronous sendAYT() method checking for status of a telnet session - getLocalOptionState() getRemoteOptionState() methods for checking the state of the negotiated options on both ends of the telnet session. A brief description of the patch: - TelnetOptionHandler is a new interface that defines the interface that must be implemented to plug into TelnetClient a user provided option handling logic. - SimpleTelnetOptionHandler is a simple class implementing TelnetOptionHandler which can be used for typical telnet communication requirements. - TelnetInputStream has been modifies to handle option subnegotiation and AYT response checking. - Telnet has been modified by adding new constructors, for handling TERMINAL-TYPE and for driving the control of option negotiation through the user provided TelnetOptionHandler instance. - TelnetClient has been modified by adding new constructors and interface methods. - TelnetClientExample1 is an example terminal that uses an external TelnetOptionHandler and demonstrates use of sendAYT(), getLocalOptionState(), getRemoteOptionState(). - TelnetClientExample2 is the same example terminal without use of the external option handler but using the built in TERMINAL-TYPE support. Please, for any comments or doubts on this patch contact me without hesitation. Also, if this is not the right procedure to submit a patch, please give me a hint on how to do that. Best regards, Bruno D'Avanzo commons-net-openoption-patch.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 for implementing support for other telnet options. I think that the best way to do this could be defining a java interface for managing options and letting users of the library define their own class for managing options. Sounds good. Submit a patch. The included patch only deals with TERMINAL-TYPE. I'll try to send a patch for an open-option version of the TelnetClient by March 17th: I have a clear idea of how to do that, but I'm facing a hard schedule on my job right now :-( Best regards, Bruno D'Avanzo terminal-type-patch.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 results in a problem in the negotiation the second time you try to accept an option. The enclose classes fix this bug (modified Telnet.java, _connectAction_ to fix the bug) Please ignore the patch I sent before, this new patch includes all the preceeding + the BUGFIX. Best regards, Bruno D'Avanzo 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 for implementing support for other telnet options. I think that the best way to do this could be defining a java interface for managing options and letting users of the library define their own class for managing options. Sounds good. Submit a patch. The included patch only deals with TERMINAL-TYPE. I'll try to send a patch for an open-option version of the TelnetClient by March 17th: I have a clear idea of how to do that, but I'm facing a hard schedule on my job right now :-( terminal-type-patch.ZIP Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding TERMINAL-TYPE option to TelnetClient
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 (org.apache.commons.net.telnet.TelnetClient). A brief description of the modification I had to make for the added capability follows: - The state machine implemented in TelnetInputStream has been extended to support option subnegotiation (can be reused for implementing support for more option requiring subnegotiation) - The Telnet base class has been extended to drive the subnegotiation sending the terminal type to the other telnet party when requested - A new constructor has been added to the TelnetClient class, which accepts a String specifying the terminal type (the default terminal type is VT100, which is took when using the empty construvtor). 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 in the Jakarta code base. Also, I think that the support for subnegotiating options can be reused for implementing support for other telnet options. I think that the best way to do this could be defining a java interface for managing options and letting users of the library define their own class for managing options. Any comment will be greatly appreciated. Bruno D'Avanzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding TERMINAL-TYPE option to TelnetClient
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 TelnetClient is an ugly hack right now. It was developed primarily to support the small bit of Telnet conversation that occurs in the FTP protocol. It also was trying to work around the constraints of java.net in the JDK 1.0.2 and 1.1 days. It can be made much more efficient today, but until decisions are made about what Java versions we want to support, I don't sense a rewrite coming along soon (besides java.nio's selectable channels are buggy on Linux, so I don't think committing to JDK 1.4 isn't even an option right now). In any case, with that disclaimer, I'm sure everyone concerned feels that any improvements to make TelnetClient more useful would be great! Also, I think that the support for subnegotiating options can be reused for implementing support for other telnet options. I think that the best way to do this could be defining a java interface for managing options and letting users of the library define their own class for managing options. Sounds good. Submit a patch. TelnetClient never got as far as working out a reusable way of dealing with the incredible variety of telnet options, so adding one is a good idea. Caveat: I'm procrastinating right now and really shouldn't be chatting about stuff I don't have the time to help out with. I'm not sure how Jeffrey and Steve are doing on time, so your patch may not be reviewed and applied or commented on immediately unless some other Commons committer with a hankering to improve Commons Net takes it up. I can promise to take some action on a patch by March 26th if no one else does. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
