[jira] Closed: (LANG-681) Move WordUtils into the text package
[ https://issues.apache.org/jira/browse/LANG-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-681. -- Resolution: Fixed Fix Version/s: 3.0 > Move WordUtils into the text package > > > Key: LANG-681 > URL: https://issues.apache.org/jira/browse/LANG-681 > Project: Commons Lang > Issue Type: Task >Reporter: Henri Yandell > Fix For: 3.0 > > > Noting in JIRA that this happened in 3.0. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (LANG-681) Move WordUtils into the text package
Move WordUtils into the text package Key: LANG-681 URL: https://issues.apache.org/jira/browse/LANG-681 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Noting in JIRA that this happened in 3.0. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (LANG-677) DateUtils.isSameLocalTime does not work correct
[ https://issues.apache.org/jira/browse/LANG-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened LANG-677: > DateUtils.isSameLocalTime does not work correct > --- > > Key: LANG-677 > URL: https://issues.apache.org/jira/browse/LANG-677 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* > Environment: linux 2.6.32-28, java version "1.6.0_22" >Reporter: Christian > Fix For: 3.0, 2.x > > > Hi, I think I found a bug in the DateUtils class in the method > isSameLocalTime. > Example: > Calendar a = Calendar.getInstance(); > a.setTimeInMillis(129736440L); > Calendar b = Calendar.getInstance(); > b.setTimeInMillis(129732120L); > Assert.assertFalse(DateUtils.isSameLocalTime(a, b)); > This is because the method compares > cal1.get(Calendar.HOUR) == cal2.get(Calendar.HOUR) > but I think it has to be > cal1.get(Calendar.HOUR_OF_DAY) == cal2.get(Calendar.HOUR_OF_DAY) > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-489) Create migrate guide to Lang 3.0
[ https://issues.apache.org/jira/browse/LANG-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001860#comment-13001860 ] Henri Yandell commented on LANG-489: By which I mean obvious 2.x references. > Create migrate guide to Lang 3.0 > > > Key: LANG-489 > URL: https://issues.apache.org/jira/browse/LANG-489 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Reporter: Henri Yandell > Fix For: 3.0 > > > Containing lots of: > Deprecated: > CharSetUtils.translate... use StringUtils.replaceChars. > Basically pull text from the old javadoc based on the items being listed in > the parent. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (LANG-677) DateUtils.isSameLocalTime does not work correct
[ https://issues.apache.org/jira/browse/LANG-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-677. -- Resolution: Fixed Fix Version/s: (was: 3.1) 3.0 > DateUtils.isSameLocalTime does not work correct > --- > > Key: LANG-677 > URL: https://issues.apache.org/jira/browse/LANG-677 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* > Environment: linux 2.6.32-28, java version "1.6.0_22" >Reporter: Christian > Fix For: 3.0, 2.x > > > Hi, I think I found a bug in the DateUtils class in the method > isSameLocalTime. > Example: > Calendar a = Calendar.getInstance(); > a.setTimeInMillis(129736440L); > Calendar b = Calendar.getInstance(); > b.setTimeInMillis(129732120L); > Assert.assertFalse(DateUtils.isSameLocalTime(a, b)); > This is because the method compares > cal1.get(Calendar.HOUR) == cal2.get(Calendar.HOUR) > but I think it has to be > cal1.get(Calendar.HOUR_OF_DAY) == cal2.get(Calendar.HOUR_OF_DAY) > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-679) StringUtils.startsWithIgnoreCase whrong documentation
[
https://issues.apache.org/jira/browse/LANG-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001858#comment-13001858
]
Henri Yandell commented on LANG-679:
Do you mean these examples?
StringUtils.startsWithIgnoreCase(null, null) = true
StringUtils.startsWithIgnoreCase(null, "abc") = false
StringUtils.startsWithIgnoreCase("abcdef", null) = false
StringUtils.startsWithIgnoreCase("abcdef", "abc") = true
StringUtils.startsWithIgnoreCase("ABCDEF", "abc") = true
If so, what's wrong with them?
> StringUtils.startsWithIgnoreCase whrong documentation
> -
>
> Key: LANG-679
> URL: https://issues.apache.org/jira/browse/LANG-679
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.4
>Reporter: Michael Neifeld
>
> Examples within JavaDoc misleads about parameters - according to examples the
> string and the prefix misplaced.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (LANG-489) Create migrate guide to Lang 3.0
[ https://issues.apache.org/jira/browse/LANG-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-489. -- Resolution: Fixed Closing. User guide was updated to remove obvious 3.0 references. > Create migrate guide to Lang 3.0 > > > Key: LANG-489 > URL: https://issues.apache.org/jira/browse/LANG-489 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Reporter: Henri Yandell > Fix For: 3.0 > > > Containing lots of: > Deprecated: > CharSetUtils.translate... use StringUtils.replaceChars. > Basically pull text from the old javadoc based on the items being listed in > the parent. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-335) TelnetOutputStream incorrectly doubles-up IAC when sending IAC+EOR in BINARY transmission mode
[
https://issues.apache.org/jira/browse/NET-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-335.
--
Resolution: Not A Problem
This is not a bug; see NET-335 for enhancement request to allow sending of IAC
commands
> TelnetOutputStream incorrectly doubles-up IAC when sending IAC+EOR in BINARY
> transmission mode
> --
>
> Key: NET-335
> URL: https://issues.apache.org/jira/browse/NET-335
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
>Affects Versions: 1.4, 2.0
> Environment: Windows XP SP3, Java 1.6.0_21
>Reporter: Chris Jones
>
> This is related to NET-180 which I reported a couple of years back, and is
> reported fixed in 2.1. I've since re-visited the code, and found another issue
> background
>
> I have a TN5250 client (see rfc1205) which extends TelnetClient. Basically,
> the client negotiates BINARY transmission and operates in block-mode. The
> client sends IAC+EOR to notify the host that the data is complete, but the
> TelnetOutputStream doubles-up the IAC automatically as if it was a data byte,
> which iis not the case, resulting in IAC+IAC+EOR.
> Two possible solutions come to mind:
> 1. Do not double-up IAC when in BINARY transmission in TelnetOutputStream
> (i.e. leave it to the client)
> 2. Add a method to TelnetClient like -- sendCommand(byte b) {} which
> would act similar to sendAYT, only allowing the client to specify the value.
> On balance, I like the second option, as it would give more future
> possibilities.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-361) Implement Telnet Command sender
Implement Telnet Command sender --- Key: NET-361 URL: https://issues.apache.org/jira/browse/NET-361 Project: Commons Net Issue Type: New Feature Components: Telnet Affects Versions: 2.2 Reporter: Sebb Assignee: Sebb TelnetClient offers sendAYT() and sendSubnegotiation() methods for sending some types of commands, but there is currently no support for sending AO, IP, EL, EC etc. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-173) Duplicate IAC when sending a IAC using TelnetClient.getOutputStream()
[
https://issues.apache.org/jira/browse/NET-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001837#comment-13001837
]
Sebb commented on NET-173:
--
Also one can send options when opening a connection (via a
TelnetOptionHandler), and there is TelnetClient#sendAYT(long).
> Duplicate IAC when sending a IAC using TelnetClient.getOutputStream()
> -
>
> Key: NET-173
> URL: https://issues.apache.org/jira/browse/NET-173
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Linux
>Reporter: Scott Burch
>Priority: Blocker
>
> TelnetOutputStream.java appears to have a bug that if we send a IAC to the
> stream returned by TelnetClient.getOutputStream() we get duplicate IAC
> commands to the telnet server.
> I looked through the code and I think I have found the reason.
> Line 82-85 appears to just send two IAC commands.
> 82 case TelnetCommand.IAC:
> 83 __client._sendByte(TelnetCommand.IAC);
> 84 __client._sendByte(TelnetCommand.IAC);
> 85 break;
> Line 91-95 appears to send the original character (which is a IAC) and a IAC
> thus producing two IACs in the stream.
> 91 else if (ch == TelnetCommand.IAC)
> 92 {
> 93 __client._sendByte(ch);
> 94 __client._sendByte(TelnetCommand.IAC);
> 95 }
> 50 public void write(int ch) throws IOException
> 51 {
> 52
> 53 synchronized (__client)
> 54 {
> 55 ch &= 0xff;
> 56
> 57 if (__client._requestedWont(TelnetOption.BINARY))
> 58 {
> 59 if (__lastWasCR)
> 60 {
> 61 if (__convertCRtoCRLF)this
> 62 {
> 63 __client._sendByte('\n');
> 64 if (ch == '\n')
> 65 {
> 66 __lastWasCR = false;
> 67 return ;
> 68 }
> 69 }
> 70 else if (ch != '\n')
> 71 __client._sendByte('\0');
> 72 }
> 73
> 74 __lastWasCR = false;
> 75
> 76 switch (ch)
> 77 {
> 78 case '\r':
> 79 __client._sendByte('\r');
> 80 __lastWasCR = true;
> 81 break;
> 82 case TelnetCommand.IAC:
> 83 __client._sendByte(TelnetCommand.IAC);
> 84 __client._sendByte(TelnetCommand.IAC);
> 85 break;
> 86 default:
> 87 __client._sendByte(ch);
> 88 break;
> 89 }
> 90 }
> 91 else if (ch == TelnetCommand.IAC)
> 92 {
> 93 __client._sendByte(ch);
> 94 __client._sendByte(TelnetCommand.IAC);
> 95 }
> 96 else
> 97 __client._sendByte(ch);
> 98 }
> 99 }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-173) Duplicate IAC when sending a IAC using TelnetClient.getOutputStream()
[
https://issues.apache.org/jira/browse/NET-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001836#comment-13001836
]
Sebb commented on NET-173:
--
Note that TelnetClient#sendSubNegotiation(int []) can be used to send an IAC SB
n n n IAC SE sequence, but currently there is no way to send other IAC commands.
> Duplicate IAC when sending a IAC using TelnetClient.getOutputStream()
> -
>
> Key: NET-173
> URL: https://issues.apache.org/jira/browse/NET-173
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Linux
>Reporter: Scott Burch
>Priority: Blocker
>
> TelnetOutputStream.java appears to have a bug that if we send a IAC to the
> stream returned by TelnetClient.getOutputStream() we get duplicate IAC
> commands to the telnet server.
> I looked through the code and I think I have found the reason.
> Line 82-85 appears to just send two IAC commands.
> 82 case TelnetCommand.IAC:
> 83 __client._sendByte(TelnetCommand.IAC);
> 84 __client._sendByte(TelnetCommand.IAC);
> 85 break;
> Line 91-95 appears to send the original character (which is a IAC) and a IAC
> thus producing two IACs in the stream.
> 91 else if (ch == TelnetCommand.IAC)
> 92 {
> 93 __client._sendByte(ch);
> 94 __client._sendByte(TelnetCommand.IAC);
> 95 }
> 50 public void write(int ch) throws IOException
> 51 {
> 52
> 53 synchronized (__client)
> 54 {
> 55 ch &= 0xff;
> 56
> 57 if (__client._requestedWont(TelnetOption.BINARY))
> 58 {
> 59 if (__lastWasCR)
> 60 {
> 61 if (__convertCRtoCRLF)this
> 62 {
> 63 __client._sendByte('\n');
> 64 if (ch == '\n')
> 65 {
> 66 __lastWasCR = false;
> 67 return ;
> 68 }
> 69 }
> 70 else if (ch != '\n')
> 71 __client._sendByte('\0');
> 72 }
> 73
> 74 __lastWasCR = false;
> 75
> 76 switch (ch)
> 77 {
> 78 case '\r':
> 79 __client._sendByte('\r');
> 80 __lastWasCR = true;
> 81 break;
> 82 case TelnetCommand.IAC:
> 83 __client._sendByte(TelnetCommand.IAC);
> 84 __client._sendByte(TelnetCommand.IAC);
> 85 break;
> 86 default:
> 87 __client._sendByte(ch);
> 88 break;
> 89 }
> 90 }
> 91 else if (ch == TelnetCommand.IAC)
> 92 {
> 93 __client._sendByte(ch);
> 94 __client._sendByte(TelnetCommand.IAC);
> 95 }
> 96 else
> 97 __client._sendByte(ch);
> 98 }
> 99 }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (NET-268) SubnetUtilsTest does not include any tests for CIDR with /30, /31, /32
[ https://issues.apache.org/jira/browse/NET-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened NET-268: -- Not fixed > SubnetUtilsTest does not include any tests for CIDR with /30, /31, /32 > --- > > Key: NET-268 > URL: https://issues.apache.org/jira/browse/NET-268 > Project: Commons Net > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Sebb > > SubnetUtilsTest does not include any tests for CIDRs with masks of /30, /31, > /32 > It only includes tests for /8 /16 /24 and /29, plus a test for the (invalid) > /0. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-258) Implement A Keepalive Mechanism
[ https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-258: - Fix Version/s: 3.0 > Implement A Keepalive Mechanism > --- > > Key: NET-258 > URL: https://issues.apache.org/jira/browse/NET-258 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 2.0 >Reporter: Rory Winston > Fix For: 3.0 > > Attachments: ftp-keepalive.diff > > > For routers/firewalls that terminate idle connections, a separate heartbeat > mechanism may need to be implemented to keep the control connection active. > Some potential issues: > * Synchronization between a heartbeat write and a __getReply() on an active > control connection command; > * Should use the NOOP command as a heartbeat signal; > * Make the timeout configurable; > * Default SocketImpl::setKeepAlive() wont do here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-286) Unhandled SecurityException in DefaultFTPFileEntryParserFactory.createFileEntryParser when using applets
[
https://issues.apache.org/jira/browse/NET-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-286:
-
Affects Version/s: 2.2
Fix Version/s: 3.0
> Unhandled SecurityException in
> DefaultFTPFileEntryParserFactory.createFileEntryParser when using applets
>
>
> Key: NET-286
> URL: https://issues.apache.org/jira/browse/NET-286
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.0
>Reporter: Jory Geerts
>Priority: Minor
> Fix For: 3.0
>
>
> When using a commons.net.ftp in a (signed) applet, we encountered an
> unhandles _SecurityException_ in
> _DefaultFTPFileEntryParserFactory.createFileEntryParser_ in some cases.
> If the applet was being hosted on my Windows Vista devmachine, connecting to
> FTP servers was no issue.
> However, as soon as we uploaded the applet to our webserver (CentOS), things
> stopped working. After some debugging, we found that there was a
> _SecurityException_ being thrown by the following code in
> _DefaultFTPFileEntryParserFactory.createFileEntryParser_:
> {{parserClass = Class.forName(key);}}
> {{parser = (FTPFileEntryParser) parserClass.newInstance();}}
> The toString() of the exception gave:
> {{java.lang.SecurityException: class "UNIX Type: L8"'s signer information
> does not match signer information of other classes in the same package}}
> (Note: When using a different FTP server, the string was obviously different.)
> The exception got caught by the generic catchblock at the bottom that doesn't
> really do anything.
> We managed to solve this by taking the code inside the catching of
> _ClassNotFoundException_ and use that to catch the _SecurityException_.
> I hope this is somewhat helpfull. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-286) Unhandled SecurityException in DefaultFTPFileEntryParserFactory.createFileEntryParser when using applets
[
https://issues.apache.org/jira/browse/NET-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-286:
-
Affects Version/s: (was: 2.2)
2.0
> Unhandled SecurityException in
> DefaultFTPFileEntryParserFactory.createFileEntryParser when using applets
>
>
> Key: NET-286
> URL: https://issues.apache.org/jira/browse/NET-286
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.0
>Reporter: Jory Geerts
>Priority: Minor
> Fix For: 3.0
>
>
> When using a commons.net.ftp in a (signed) applet, we encountered an
> unhandles _SecurityException_ in
> _DefaultFTPFileEntryParserFactory.createFileEntryParser_ in some cases.
> If the applet was being hosted on my Windows Vista devmachine, connecting to
> FTP servers was no issue.
> However, as soon as we uploaded the applet to our webserver (CentOS), things
> stopped working. After some debugging, we found that there was a
> _SecurityException_ being thrown by the following code in
> _DefaultFTPFileEntryParserFactory.createFileEntryParser_:
> {{parserClass = Class.forName(key);}}
> {{parser = (FTPFileEntryParser) parserClass.newInstance();}}
> The toString() of the exception gave:
> {{java.lang.SecurityException: class "UNIX Type: L8"'s signer information
> does not match signer information of other classes in the same package}}
> (Note: When using a different FTP server, the string was obviously different.)
> The exception got caught by the generic catchblock at the bottom that doesn't
> really do anything.
> We managed to solve this by taking the code inside the catching of
> _ClassNotFoundException_ and use that to catch the _SecurityException_.
> I hope this is somewhat helpfull. :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-343:
-
Fix Version/s: 3.0
> Telnet client: Support Client-initiated Subnegotiation Messages
> ---
>
> Key: NET-343
> URL: https://issues.apache.org/jira/browse/NET-343
> Project: Commons Net
> Issue Type: New Feature
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Fix For: 3.0
>
> Attachments: patch1.txt
>
>
> I am in the process of trying to implement a Java client for [RFC
> 2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
> serial ports over TCP. Unfortunately, the commons-net telnet client is
> insufficient for this relatively simple task.
> There are two missing features in the commons-net telnet client code, one of
> which is a show stopper and the other of which would be a "real nice to
> have". This issue documents the first problem:
> RFC 2217 specifies that serial port events (such as server notifiying about a
> change in carrier detect, or the client instructing the server to change the
> baud rate) are delivered to the peer by subnegotiations. For example, to
> notify the client about carrier detect, the server sends {{IAC SB
> COM-PORT-OPTION NOTIFY-MODEMSTATE IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> IAC SE}} to the server. These messages can happen at any time and
> are not associated with any WILL/WONT/DO/DONT negotiation (according to my
> understanding).
> The problem is that while one can _receive_ such messages via
> {{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
> doesn't provide any way to _send_ (i.e., intiate) these messages.
> What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
> (properly renamed, etc.) as a public method.
> I'm going to attempt to come up with a patch and will attach it here if
> successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-352) [POP3] [PATCH] SASL PLAIN & CRAM-MD5 authentication
[ https://issues.apache.org/jira/browse/NET-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-352: - Affects Version/s: 2.2 Fix Version/s: 3.0 > [POP3] [PATCH] SASL PLAIN & CRAM-MD5 authentication > --- > > Key: NET-352 > URL: https://issues.apache.org/jira/browse/NET-352 > Project: Commons Net > Issue Type: New Feature > Components: POP3 >Affects Versions: 2.2 >Reporter: Bogdan Drozdowski >Priority: Minor > Fix For: 3.0 > > Attachments: ExtendedPOP3Client.java, pop3-ex.diff > > Original Estimate: 0h > Remaining Estimate: 0h > > The POP3Client does not suppport the SASL PLAIN & CRAM-MD5 authentication > mechanisms. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-357) [POP3] [Solution] The POP3 client does not support SSL/TLS connections
[ https://issues.apache.org/jira/browse/NET-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-357: - Affects Version/s: 2.2 Fix Version/s: 3.0 > [POP3] [Solution] The POP3 client does not support SSL/TLS connections > -- > > Key: NET-357 > URL: https://issues.apache.org/jira/browse/NET-357 > Project: Commons Net > Issue Type: New Feature > Components: POP3 >Affects Versions: 2.2 >Reporter: Bogdan Drozdowski >Priority: Minor > Fix For: 3.0 > > Attachments: POP3-SSL-TLS.zip > > Original Estimate: 0h > Remaining Estimate: 0h > > The POP3Client class does not support automatic SSL negotiation when > connecting to the POP3S port and it does not support TLS negotiation when > connecting to the standard POP3 port. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-203) FTPSClient uses mutable objects for CipherSuites and Protocols
[ https://issues.apache.org/jira/browse/NET-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-203: - Fix Version/s: 2.0 > FTPSClient uses mutable objects for CipherSuites and Protocols > -- > > Key: NET-203 > URL: https://issues.apache.org/jira/browse/NET-203 > Project: Commons Net > Issue Type: Bug >Affects Versions: 1.5, 2.0 >Reporter: Sebb > Fix For: 2.0 > > Attachments: FTPSClient.patch > > > FTPSClient uses mutable objects for CipherSuites and Protocols. > The setxxx methods ought to copy the arrays, rather than storing a reference > to them. > As these arrays are used in establishing a secure connection, it's important > that the data is also secure. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-345:
-
Fix Version/s: 3.0
> Telnet client: not properly handling IAC bytes within subnegotiation messages
> -
>
> Key: NET-345
> URL: https://issues.apache.org/jira/browse/NET-345
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Fix For: 3.0
>
> Attachments: patch3.txt, patch4.txt
>
>
> Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
> IAC SE}}.
> Although it's not clearly spelled out in [RFC
> 854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
> these messages must be escaped by doubling. Other clients do this and this is
> the only behavior that makes sense.
> The commons-net telnet client is failing both to escape and to unescape
> {{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
> valid {{IAC IAC}} sequence within a subnegotiation message, it will
> incorrectly jump back to "data" input mode, discarding the message and
> introducing its remainder as garbage in the data stream.
> In addition, the code fails to check for an overflow of the subnegotiation
> buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
> malicious peer triggered this condition.
> Finally, a {{IAC SE}} sequence appearing by itself should probably be
> discarded, rather than passing as a command to the handler.
> I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-345.
--
Resolution: Fixed
Thanks, applied patches with a few minor changes.
E.g. output is buffered, so simpler to double the IACs on the fly rather than
using another buffer.
> Telnet client: not properly handling IAC bytes within subnegotiation messages
> -
>
> Key: NET-345
> URL: https://issues.apache.org/jira/browse/NET-345
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: patch3.txt, patch4.txt
>
>
> Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
> IAC SE}}.
> Although it's not clearly spelled out in [RFC
> 854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
> these messages must be escaped by doubling. Other clients do this and this is
> the only behavior that makes sense.
> The commons-net telnet client is failing both to escape and to unescape
> {{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
> valid {{IAC IAC}} sequence within a subnegotiation message, it will
> incorrectly jump back to "data" input mode, discarding the message and
> introducing its remainder as garbage in the data stream.
> In addition, the code fails to check for an overflow of the subnegotiation
> buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
> malicious peer triggered this condition.
> Finally, a {{IAC SE}} sequence appearing by itself should probably be
> discarded, rather than passing as a command to the handler.
> I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001771#comment-13001771
]
Sebb commented on NET-343:
--
Sorry, we can only use patches that are provided as attachments.
This is partly for historic traceability and partly because of the ASF license
grant that is provided.
> Telnet client: Support Client-initiated Subnegotiation Messages
> ---
>
> Key: NET-343
> URL: https://issues.apache.org/jira/browse/NET-343
> Project: Commons Net
> Issue Type: New Feature
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: patch1.txt
>
>
> I am in the process of trying to implement a Java client for [RFC
> 2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
> serial ports over TCP. Unfortunately, the commons-net telnet client is
> insufficient for this relatively simple task.
> There are two missing features in the commons-net telnet client code, one of
> which is a show stopper and the other of which would be a "real nice to
> have". This issue documents the first problem:
> RFC 2217 specifies that serial port events (such as server notifiying about a
> change in carrier detect, or the client instructing the server to change the
> baud rate) are delivered to the peer by subnegotiations. For example, to
> notify the client about carrier detect, the server sends {{IAC SB
> COM-PORT-OPTION NOTIFY-MODEMSTATE IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> IAC SE}} to the server. These messages can happen at any time and
> are not associated with any WILL/WONT/DO/DONT negotiation (according to my
> understanding).
> The problem is that while one can _receive_ such messages via
> {{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
> doesn't provide any way to _send_ (i.e., intiate) these messages.
> What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
> (properly renamed, etc.) as a public method.
> I'm going to attempt to come up with a patch and will attach it here if
> successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001730#comment-13001730
]
Archie Cobbs commented on NET-343:
--
Ok nevermind previous comment, patch1.txt is pretty trivial and hasn't changed
since originally posted. Thanks.
> Telnet client: Support Client-initiated Subnegotiation Messages
> ---
>
> Key: NET-343
> URL: https://issues.apache.org/jira/browse/NET-343
> Project: Commons Net
> Issue Type: New Feature
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: patch1.txt
>
>
> I am in the process of trying to implement a Java client for [RFC
> 2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
> serial ports over TCP. Unfortunately, the commons-net telnet client is
> insufficient for this relatively simple task.
> There are two missing features in the commons-net telnet client code, one of
> which is a show stopper and the other of which would be a "real nice to
> have". This issue documents the first problem:
> RFC 2217 specifies that serial port events (such as server notifiying about a
> change in carrier detect, or the client instructing the server to change the
> baud rate) are delivered to the peer by subnegotiations. For example, to
> notify the client about carrier detect, the server sends {{IAC SB
> COM-PORT-OPTION NOTIFY-MODEMSTATE IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> IAC SE}} to the server. These messages can happen at any time and
> are not associated with any WILL/WONT/DO/DONT negotiation (according to my
> understanding).
> The problem is that while one can _receive_ such messages via
> {{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
> doesn't provide any way to _send_ (i.e., intiate) these messages.
> What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
> (properly renamed, etc.) as a public method.
> I'm going to attempt to come up with a patch and will attach it here if
> successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001728#comment-13001728
]
Archie Cobbs commented on NET-343:
--
Just to confirm: patch1.txt is/may be obsolete, please use [this combined
patch|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].
Thanks.
> Telnet client: Support Client-initiated Subnegotiation Messages
> ---
>
> Key: NET-343
> URL: https://issues.apache.org/jira/browse/NET-343
> Project: Commons Net
> Issue Type: New Feature
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: patch1.txt
>
>
> I am in the process of trying to implement a Java client for [RFC
> 2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
> serial ports over TCP. Unfortunately, the commons-net telnet client is
> insufficient for this relatively simple task.
> There are two missing features in the commons-net telnet client code, one of
> which is a show stopper and the other of which would be a "real nice to
> have". This issue documents the first problem:
> RFC 2217 specifies that serial port events (such as server notifiying about a
> change in carrier detect, or the client instructing the server to change the
> baud rate) are delivered to the peer by subnegotiations. For example, to
> notify the client about carrier detect, the server sends {{IAC SB
> COM-PORT-OPTION NOTIFY-MODEMSTATE IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> IAC SE}} to the server. These messages can happen at any time and
> are not associated with any WILL/WONT/DO/DONT negotiation (according to my
> understanding).
> The problem is that while one can _receive_ such messages via
> {{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
> doesn't provide any way to _send_ (i.e., intiate) these messages.
> What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
> (properly renamed, etc.) as a public method.
> I'm going to attempt to come up with a patch and will attach it here if
> successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-343.
--
Resolution: Fixed
Thanks, patch1.txt applied.
It's easier to apply patches if they are created relative to the code root,
i.e. the location of the pom.xml.
> Telnet client: Support Client-initiated Subnegotiation Messages
> ---
>
> Key: NET-343
> URL: https://issues.apache.org/jira/browse/NET-343
> Project: Commons Net
> Issue Type: New Feature
> Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: patch1.txt
>
>
> I am in the process of trying to implement a Java client for [RFC
> 2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
> serial ports over TCP. Unfortunately, the commons-net telnet client is
> insufficient for this relatively simple task.
> There are two missing features in the commons-net telnet client code, one of
> which is a show stopper and the other of which would be a "real nice to
> have". This issue documents the first problem:
> RFC 2217 specifies that serial port events (such as server notifiying about a
> change in carrier detect, or the client instructing the server to change the
> baud rate) are delivered to the peer by subnegotiations. For example, to
> notify the client about carrier detect, the server sends {{IAC SB
> COM-PORT-OPTION NOTIFY-MODEMSTATE IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> IAC SE}} to the server. These messages can happen at any time and
> are not associated with any WILL/WONT/DO/DONT negotiation (according to my
> understanding).
> The problem is that while one can _receive_ such messages via
> {{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
> doesn't provide any way to _send_ (i.e., intiate) these messages.
> What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
> (properly renamed, etc.) as a public method.
> I'm going to attempt to come up with a patch and will attach it here if
> successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-270) Incorrect error handling in method initiateListParsing of FTPClient
[
https://issues.apache.org/jira/browse/NET-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-270.
--
Resolution: Fixed
Fix Version/s: 3.0
Fixed by calling Util.closeQuietly(socket); instead of socket.close() in
private FTPListParseEngine initiateListParsing
> Incorrect error handling in method initiateListParsing of FTPClient
> ---
>
> Key: NET-270
> URL: https://issues.apache.org/jira/browse/NET-270
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.0
> Environment: XP - java version "1.5.0_09" - FileZilla server
> 0.9.30beta
>Reporter: Gilles Gaillard
> Fix For: 3.0
>
> Attachments: FTPClientUnitTest.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In method initiateListParsing of FTPClient, errors when opening the data
> connection are not correctly handled.
> This leads to ignore message delivered by the server and further operation
> with the FTPClient instance are not valid.
> As an example, considere the attached unit test. When such an error is met,
> using the _sendNoOp_ command returns false.
> Here is an output of the test:
> {noformat}
> F:\dev\jakarta\>run org.apache.commons.vfs.provider.ftp.FTPClientUnitTest
> 10.0.0.x 21 /GILLES/source usr pass 5500
> Ignoring error when creating client at iteration: 1152
> Error at iteration: 1155
> java.net.SocketTimeoutException: Accept timed out
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
> at java.net.ServerSocket.implAccept(ServerSocket.java:450)
> at java.net.ServerSocket.accept(ServerSocket.java:421)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
> at
> org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2296)
> at
> org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2269)
> at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2046)
> at
> org.apache.commons.vfs.provider.ftp.FTPClientUnitTest.testConnectTimeoutInList(FTPClientUnitTest.java:70)
> at
> org.apache.commons.vfs.provider.ftp.FTPClientUnitTest.main(FTPClientUnitTest.java:110)
> Exception in thread "main" junit.framework.AssertionFailedError: NOOP failed
> at iteration 1155
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> org.apache.commons.vfs.provider.ftp.FTPClientUnitTest.testConnectTimeoutInList(FTPClientUnitTest.java:75)
> at
> org.apache.commons.vfs.provider.ftp.FTPClientUnitTest.main(FTPClientUnitTest.java:110)
> {noformat}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-220) TFTPServer is not threadsafe
[ https://issues.apache.org/jira/browse/NET-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-220. -- Resolution: Won't Fix The server is now a test class only, and the patches no longer apply cleanly. > TFTPServer is not threadsafe > > > Key: NET-220 > URL: https://issues.apache.org/jira/browse/NET-220 > Project: Commons Net > Issue Type: Bug > Components: TFTP >Affects Versions: 2.0 >Reporter: Sebb > Attachments: TFTPServer.patch, TFTPServerPathTest.patch > > > The TFTPServer class is not threadsafe. > There are several reasons for this: > Ctors call private launch() method which creates a thread and start()s it. > This publishes the instance before it has been fully constructed. > Various instance fields are not thread-safe - e.g. serverReadDirectory_ is > neither final nor volatile, and accesses to it are not synchronized. > Although it is only written by the ctors, the lack of synch means that the > field may not be visible to other threads. > As far as possible, instance fields should be made final - this guarantees > that the field will be visible to other threads. > One of the shutdown_ variables is volatile (so is threadsafe) but the > shutdown_ variable in the nested TFTPTransfer class is not, yet is accessed > from multiple threads. > The access to the variable serverException is not synch; should probably be > volatile. > Patch to follow. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (NET-284) problem with TelnetClient.setSoTimeout() : not the proper behaviour
[
https://issues.apache.org/jira/browse/NET-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb closed NET-284.
> problem with TelnetClient.setSoTimeout() : not the proper behaviour
> ---
>
> Key: NET-284
> URL: https://issues.apache.org/jira/browse/NET-284
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
>Affects Versions: 2.0
> Environment: Windows XP, Sun JRE 6
>Reporter: dalouuu
>
> Hi all,
> Correct me if I'm wrong but I think that the telnetClient is not handling
> properly timeouts.
> Just look at this junit testCase :
> {code}
> import java.io.BufferedReader;
> import java.io.IOException;
> import java.io.InputStreamReader;
> import java.io.PrintWriter;
> import java.net.SocketException;
> import java.net.SocketTimeoutException;
> import junit.framework.TestCase;
> import org.apache.commons.net.telnet.*;
> import org.junit.Test;
> public class TelnetClientTest extends TestCase {
> private TelnetClient telnetClient;
> private BufferedReader in= null;
> private PrintWriter out= null;
>
> @Test
> public void testSetSoTimeout() {
>
> telnetClient = new TelnetClient();
>
> /*
>* FIRST SCRIPT
>*/
> try {
> telnetClient.connect("192.168.0.95", 23);
> } catch (SocketException e) {
> e.printStackTrace();
> this.disconnect();
> fail("Error connect");
> } catch (IOException e) {
> e.printStackTrace();
> this.disconnect();
> fail("Error connect");
> }
> assertTrue ("telnet client not connected",
> telnetClient.isConnected());
>
> in = new BufferedReader(new
> InputStreamReader(telnetClient.getInputStream()));
> out = new PrintWriter(telnetClient.getOutputStream());
> String mes = null;
>
> // LOGIN
> mes = getMessageFromTelnetServer(300);
> assertNotNull("mes is null", mes);
> assertTrue("Pas de prompt login", mes.endsWith("login: "));
> out.println("root");
> out.flush();
>
> // PASSWORD
> mes = getMessageFromTelnetServer(300);
> assertNotNull("mes is null", mes);
> assertTrue("Pas de prompt password", mes.endsWith("Password:
> "));
> out.println("rootpwd");
> out.flush();
>
> // PROMPT
> mes = getMessageFromTelnetServer(300);
> assertNotNull("mes is null", mes);
> assertTrue("no prompt", mes.endsWith("$ "));
>
> // SEND PWD
> out.println("pwd");
> out.flush();
>
> // WAIT A LITTLE BIT TOO MUCH
> try {
> Thread.sleep(1000);
> } catch(InterruptedException e) {
> }
>
> // READ RESULT OF PWD
> mes = getMessageFromTelnetServer(300);
>
> // READ AGAIN ... YES !
> String mes2 = getMessageFromTelnetServer(300);
>
> // CRASH HERE
> assertTrue("no result to pwd", mes.endsWith("$ "));
>
> // AND HERE
> assertEquals("should be empty but we get result of pwd", "" ,
> mes2);
>
> this.disconnect();
>
> }
>
> private void disconnect() {
> try {
> telnetClient.disconnect();
> } catch (IOException e) {}
> }
>
> private String getMessageFromTelnetServer(int timeout) {
> int numberOfBytes = 0;
> char[] msgChar = new char[2000];
>
> try {
> telnetClient.setSoTimeout(timeout);
> } catch (Exception e) {
> return "";
> }
>
> String res = "";
> read_loop:
> while (numberOfBytes >= 0) {
> try {
> numberOfBytes = in.read(msgChar, 0,
> msgChar.length);
> } catch (SocketTimeoutException e) {
> break read_loop;
> } catch (IOException e) {
> e.printStackTrace();
> break read_loop;
> }
> res =
[jira] Resolved: (NET-284) problem with TelnetClient.setSoTimeout() : not the proper behaviour
[
https://issues.apache.org/jira/browse/NET-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-284.
--
Resolution: Invalid
setSoTimeout calls java.net.Socket.setSoTimeout(int timeout) which only affects
how long a read operation will take.
> problem with TelnetClient.setSoTimeout() : not the proper behaviour
> ---
>
> Key: NET-284
> URL: https://issues.apache.org/jira/browse/NET-284
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
>Affects Versions: 2.0
> Environment: Windows XP, Sun JRE 6
>Reporter: dalouuu
>
> Hi all,
> Correct me if I'm wrong but I think that the telnetClient is not handling
> properly timeouts.
> Just look at this junit testCase :
> {code}
> import java.io.BufferedReader;
> import java.io.IOException;
> import java.io.InputStreamReader;
> import java.io.PrintWriter;
> import java.net.SocketException;
> import java.net.SocketTimeoutException;
> import junit.framework.TestCase;
> import org.apache.commons.net.telnet.*;
> import org.junit.Test;
> public class TelnetClientTest extends TestCase {
> private TelnetClient telnetClient;
> private BufferedReader in= null;
> private PrintWriter out= null;
>
> @Test
> public void testSetSoTimeout() {
>
> telnetClient = new TelnetClient();
>
> /*
>* FIRST SCRIPT
>*/
> try {
> telnetClient.connect("192.168.0.95", 23);
> } catch (SocketException e) {
> e.printStackTrace();
> this.disconnect();
> fail("Error connect");
> } catch (IOException e) {
> e.printStackTrace();
> this.disconnect();
> fail("Error connect");
> }
> assertTrue ("telnet client not connected",
> telnetClient.isConnected());
>
> in = new BufferedReader(new
> InputStreamReader(telnetClient.getInputStream()));
> out = new PrintWriter(telnetClient.getOutputStream());
> String mes = null;
>
> // LOGIN
> mes = getMessageFromTelnetServer(300);
> assertNotNull("mes is null", mes);
> assertTrue("Pas de prompt login", mes.endsWith("login: "));
> out.println("root");
> out.flush();
>
> // PASSWORD
> mes = getMessageFromTelnetServer(300);
> assertNotNull("mes is null", mes);
> assertTrue("Pas de prompt password", mes.endsWith("Password:
> "));
> out.println("rootpwd");
> out.flush();
>
> // PROMPT
> mes = getMessageFromTelnetServer(300);
> assertNotNull("mes is null", mes);
> assertTrue("no prompt", mes.endsWith("$ "));
>
> // SEND PWD
> out.println("pwd");
> out.flush();
>
> // WAIT A LITTLE BIT TOO MUCH
> try {
> Thread.sleep(1000);
> } catch(InterruptedException e) {
> }
>
> // READ RESULT OF PWD
> mes = getMessageFromTelnetServer(300);
>
> // READ AGAIN ... YES !
> String mes2 = getMessageFromTelnetServer(300);
>
> // CRASH HERE
> assertTrue("no result to pwd", mes.endsWith("$ "));
>
> // AND HERE
> assertEquals("should be empty but we get result of pwd", "" ,
> mes2);
>
> this.disconnect();
>
> }
>
> private void disconnect() {
> try {
> telnetClient.disconnect();
> } catch (IOException e) {}
> }
>
> private String getMessageFromTelnetServer(int timeout) {
> int numberOfBytes = 0;
> char[] msgChar = new char[2000];
>
> try {
> telnetClient.setSoTimeout(timeout);
> } catch (Exception e) {
> return "";
> }
>
> String res = "";
> read_loop:
> while (numberOfBytes >= 0) {
> try {
> numberOfBytes = in.read(msgChar, 0,
> msgChar.length);
> } catch (SocketTimeoutException e) {
> break read_loop;
> } catch (IOException e) {
>
[jira] Resolved: (NET-315) listFiles() locks up under 2.1, but works under 2.0
[ https://issues.apache.org/jira/browse/NET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-315. -- Resolution: Fixed Fix Version/s: 2.2 Fixed in NET-313 > listFiles() locks up under 2.1, but works under 2.0 > --- > > Key: NET-315 > URL: https://issues.apache.org/jira/browse/NET-315 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.1 > Environment: Ubuntu x86_64 9.04, Java x86_64 1.6.0_16-b01 >Reporter: Andy Brook > Fix For: 2.2 > > Attachments: commons-net-problem.zip > > > I have several servers that I'm spidering with FTPClient, I initially thought > there was something wrong with what Im doing, however, dropping the version > back to 2.0, and what I'm seeing goes away. > the following 'System Names' exhibit this lockup behaviour: > ||System || Works|| Notes || > |UNIX Type\: L8| (x)| several sites Im talking to respond with this | > |System Name\: null | (x) | I found that on connect its telling me > "Windows_NT"| > Ubuntu 6.06 and 9.04 systems work fine. > Attached will be a test-case maven project, just edit the 'blank.properties' > in resources, with valid ftp server values. With commons-net-2.1 it locks > up, but backing off to 2.0, it works. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-352) [POP3] [PATCH] SASL PLAIN & CRAM-MD5 authentication
[ https://issues.apache.org/jira/browse/NET-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-352. -- Resolution: Fixed Thanks again, patch applied to SVN > [POP3] [PATCH] SASL PLAIN & CRAM-MD5 authentication > --- > > Key: NET-352 > URL: https://issues.apache.org/jira/browse/NET-352 > Project: Commons Net > Issue Type: New Feature > Components: POP3 >Reporter: Bogdan Drozdowski >Priority: Minor > Attachments: ExtendedPOP3Client.java, pop3-ex.diff > > Original Estimate: 0h > Remaining Estimate: 0h > > The POP3Client does not suppport the SASL PLAIN & CRAM-MD5 authentication > mechanisms. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-357) [POP3] [Solution] The POP3 client does not support SSL/TLS connections
[ https://issues.apache.org/jira/browse/NET-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-357. -- Resolution: Fixed Thanks very much, applied to SVN > [POP3] [Solution] The POP3 client does not support SSL/TLS connections > -- > > Key: NET-357 > URL: https://issues.apache.org/jira/browse/NET-357 > Project: Commons Net > Issue Type: New Feature > Components: POP3 >Reporter: Bogdan Drozdowski >Priority: Minor > Attachments: POP3-SSL-TLS.zip > > Original Estimate: 0h > Remaining Estimate: 0h > > The POP3Client class does not support automatic SSL negotiation when > connecting to the POP3S port and it does not support TLS negotiation when > connecting to the standard POP3 port. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (LANG-680) StringUtils - Longest Common Substring / Longest common susequence
StringUtils - Longest Common Substring / Longest common susequence -- Key: LANG-680 URL: https://issues.apache.org/jira/browse/LANG-680 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Andrea Vacondio I recently needed to perform Longest commons substring on a collection of filenames and I think it could be usefull to have it in StringUtils (I couldn't find any discussion about it). Some detail here http://en.wikipedia.org/wiki/Longest_common_substring and here http://en.wikipedia.org/wiki/Longest_common_subsequence_problem -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (LANG-679) StringUtils.startsWithIgnoreCase whrong documentation
StringUtils.startsWithIgnoreCase whrong documentation - Key: LANG-679 URL: https://issues.apache.org/jira/browse/LANG-679 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 2.4 Reporter: Michael Neifeld Examples within JavaDoc misleads about parameters - according to examples the string and the prefix misplaced. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
