[jira] Updated: (LANG-682) Public constants on StringEscapeUtils do not have javadoc

[Henri Yandell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Yandell updated LANG-682:
---

Affects Version/s: (was: 3.0)
Fix Version/s: 3.0

> Public constants on StringEscapeUtils do not have javadoc
> -
>
> Key: LANG-682
> URL: https://issues.apache.org/jira/browse/LANG-682
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Stephen Colebourne
> Fix For: 3.0
>
>


-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (LANG-683) The StringUtils.concat methods duplicate the existing join methods

[Henri Yandell (JIRA)]

The StringUtils.concat methods duplicate the existing join methods
--

 Key: LANG-683
 URL: https://issues.apache.org/jira/browse/LANG-683
 Project: Commons Lang
  Issue Type: Bug
Reporter: Stephen Colebourne
 Fix For: 3.0




-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (LANG-682) Public constants on StringEscapeUtils do not have javadoc

[Henri Yandell (JIRA)]

Public constants on StringEscapeUtils do not have javadoc
-

 Key: LANG-682
 URL: https://issues.apache.org/jira/browse/LANG-682
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Stephen Colebourne




-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (LANG-679) StringUtils.startsWithIgnoreCase whrong documentation

[Niall Pemberton (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved LANG-679.
--

Resolution: Duplicate

Duplicates LANG-460 fixed in Lang 2.5

> 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] Resolved: (NET-344) Telnet client: Support Listener Notification of Incoming Data

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved NET-344.
--

Resolution: Fixed

Thanks, patch applied with minor modifications (e.g. removed @Override from 
TelnetInputStream.run() otherwise it does not compile with Java 1.5)

In future, please provide patches relative to the project root. Thanks.

> Telnet client: Support Listener Notification of Incoming Data
> -
>
> Key: NET-344
> URL: https://issues.apache.org/jira/browse/NET-344
> Project: Commons Net
>  Issue Type: New Feature
>  Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: NET-344_updated.txt, 
> combined_NET-343_NET-344_NET-345_patch.txt, patch2.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 (NET-343) and the other of which would be a "real 
> nice to have". This issue documents the second problem:
> The API I am trying to support requires the ability to notify a listener that 
> new incoming data is available. This would be trivial for me to do if only my 
> library could somehow itself get a listener notification from the 
> {{TelnetInputStream}} reader thread every time it reads new data. 
> Unfortunately, there's no API provided for doing this, even though it would 
> be trivial. So I have to implement a hack that requires a wrapper 
> {{InputStream}} with yet another internal reader thread, etc. Bleh.
> 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-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002123#comment-13002123
 ] 

Sebb commented on NET-345:
--

Todays attachements removed, as they are not needed for this issue.

> 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] Updated: (NET-344) Telnet client: Support Listener Notification of Incoming Data

[Archie Cobbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Archie Cobbs updated NET-344:
-

Attachment: NET-344_updated.txt

OK, {{NET-344_updated.txt}} contains just the remaining (uncommitted) part of 
the combined patch, i.e., it fixes just this issue.

Thanks,


> Telnet client: Support Listener Notification of Incoming Data
> -
>
> Key: NET-344
> URL: https://issues.apache.org/jira/browse/NET-344
> Project: Commons Net
>  Issue Type: New Feature
>  Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: NET-344_updated.txt, 
> combined_NET-343_NET-344_NET-345_patch.txt, patch2.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 (NET-343) and the other of which would be a "real 
> nice to have". This issue documents the second problem:
> The API I am trying to support requires the ability to notify a listener that 
> new incoming data is available. This would be trivial for me to do if only my 
> library could somehow itself get a listener notification from the 
> {{TelnetInputStream}} reader thread every time it reads new data. 
> Unfortunately, there's no API provided for doing this, even though it would 
> be trivial. So I have to implement a hack that requires a wrapper 
> {{InputStream}} with yet another internal reader thread, etc. Bleh.
> 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-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated NET-345:
-

Attachment: (was: discard_IAC_SE.txt)

> 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] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated NET-345:
-

Attachment: (was: combined_NET-343_NET-344_NET-345_patch.txt)

> 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] Commented: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

[Archie Cobbs (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002117#comment-13002117
 ] 

Archie Cobbs commented on NET-345:
--

Bleh! Sorry, ignore that last comment and patch ({{discard_IAC_SE.txt}}). That 
patch was already included in a slightly different form.

My apologies. I'm getting confused trying to merge all the patches.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, 
> discard_IAC_SE.txt, 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] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

[Archie Cobbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Archie Cobbs updated NET-345:
-

Attachment: discard_IAC_SE.txt

Thanks. Just the last bit of the combined patch was left out, i.e., discarding 
an IAC SE sequence appearing by itself.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, 
> discard_IAC_SE.txt, 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-344) Telnet client: Support Listener Notification of Incoming Data

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002034#comment-13002034
 ] 

Sebb commented on NET-344:
--

The other issues have been resolved.

Please attach a patch that fixes just the items necessary to complete this 
issue.


> Telnet client: Support Listener Notification of Incoming Data
> -
>
> Key: NET-344
> URL: https://issues.apache.org/jira/browse/NET-344
> Project: Commons Net
>  Issue Type: New Feature
>  Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: combined_NET-343_NET-344_NET-345_patch.txt, patch2.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 (NET-343) and the other of which would be a "real 
> nice to have". This issue documents the second problem:
> The API I am trying to support requires the ability to notify a listener that 
> new incoming data is available. This would be trivial for me to do if only my 
> library could somehow itself get a listener notification from the 
> {{TelnetInputStream}} reader thread every time it reads new data. 
> Unfortunately, there's no API provided for doing this, even though it would 
> be trivial. So I have to implement a hack that requires a wrapper 
> {{InputStream}} with yet another internal reader thread, etc. Bleh.
> 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

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002033#comment-13002033
 ] 

Sebb commented on NET-343:
--

This issue is marked as resolved. 

If there are any changes that have not been applied, please attach a patch that 
fixes just the items necessary to complete this issue.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, 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-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002032#comment-13002032
 ] 

Sebb commented on NET-345:
--

This issue is marked as resolved. 

If there are any changes that have not been applied, please attach a patch that 
fixes just the items necessary to complete this issue.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, 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: (LANG-679) StringUtils.startsWithIgnoreCase whrong documentation

[Michael Neifeld (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002024#comment-13002024
 ] 

Michael Neifeld commented on LANG-679:
--

No, I'm meaning these:

StringUtils.startsWithIgnoreCase(null, null)  = true
StringUtils.startsWithIgnoreCase(null, "abcdef")  = false
StringUtils.startsWithIgnoreCase("abc", null) = false
StringUtils.startsWithIgnoreCase("abc", "abcdef") = true
StringUtils.startsWithIgnoreCase("abc", "ABCDEF") = true

That can be found in version 2.4
As I understand this is fixed in more recent version, so it's can be closed ?

> 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] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

[Archie Cobbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Archie Cobbs updated NET-345:
-

Attachment: combined_NET-343_NET-344_NET-345_patch.txt

Attaching combined patch for NET-343, NET-344, NET-345.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, 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] Updated: (NET-344) Telnet client: Support Listener Notification of Incoming Data

[Archie Cobbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Archie Cobbs updated NET-344:
-

Attachment: combined_NET-343_NET-344_NET-345_patch.txt

Attaching combined patch for NET-343, NET-344, NET-345.


> Telnet client: Support Listener Notification of Incoming Data
> -
>
> Key: NET-344
> URL: https://issues.apache.org/jira/browse/NET-344
> Project: Commons Net
>  Issue Type: New Feature
>  Components: Telnet
>Affects Versions: 2.0
>Reporter: Archie Cobbs
> Attachments: combined_NET-343_NET-344_NET-345_patch.txt, patch2.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 (NET-343) and the other of which would be a "real 
> nice to have". This issue documents the second problem:
> The API I am trying to support requires the ability to notify a listener that 
> new incoming data is available. This would be trivial for me to do if only my 
> library could somehow itself get a listener notification from the 
> {{TelnetInputStream}} reader thread every time it reads new data. 
> Unfortunately, there's no API provided for doing this, even though it would 
> be trivial. So I have to implement a hack that requires a wrapper 
> {{InputStream}} with yet another internal reader thread, etc. Bleh.
> 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-343) Telnet client: Support Client-initiated Subnegotiation Messages

[Archie Cobbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Archie Cobbs updated NET-343:
-

Attachment: combined_NET-343_NET-344_NET-345_patch.txt

Attaching combined patch for NET-343, NET-344, NET-345.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, 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] Closed: (MATH-535) Closing the loop in function objects

[Gilles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles closed MATH-535.
---

Resolution: Not A Problem

> Closing the loop in function objects
> 
>
> Key: MATH-535
> URL: https://issues.apache.org/jira/browse/MATH-535
> Project: Commons Math
>  Issue Type: New Feature
>Reporter: Gilles
>Priority: Minor
>  Labels: api-change
> Fix For: 3.0
>
>
> Some function classes (in package "analysis.function") now contains a 
> "Parametric" inner class that provides a parametric version of the function 
> represented by the enclosing class.
> # We could enhance the "UnivariateRealFunction" interface to contain:
> {noformat}
>   public ParametricUnivariateRealFunction createParametricFunction();
> {noformat}
> which, e.g. for the "Gaussian" concrete class, would translate to:
> {noformat}
>   public Gaussian.Parametric createParametricFunction() {
> return new Gaussian.Parametric();
>   }
> {noformat}
> # We could enhance the "ParametricUnivariateRealFunction" interface to 
> contain:
> {noformat}
>   public UnivariateRealFunction createFunction(double[] param);
> {noformat}
> which, in "Gaussian.Parametric", would translate to:
> {noformat}
>   public Gaussian createFunction(double[] param) {
> validateParameters(param);
> return new Gaussian(param[0], param[1], param[2]);
>   }
> {noformat}
> In both cases, it would allow programming against interfaces.
> For the first case, not all current implementations of 
> "UnivariateRealFunction" provide a "Parametric" version (and for most there 
> are no parameters). So either we create a new 
> "AbstractUnivariateRealFunction" that provides a default implementation of 
> "createParametricFunction" (throwing an exception) and make all current 
> function classes extends this one, or we create a new interface (something 
> like "ParametricFactory") that declares the new "createParametricFunction()" 
> and add the "implements ParametricFactory" clause to any class that provides 
> a parametric version.
> I think that the latter is the cleanest. Or is there still another 
> possibility?

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (NET-362) TelnetInputStream has various threading bugs

[Sebb (JIRA)]

TelnetInputStream has various threading bugs


 Key: NET-362
 URL: https://issues.apache.org/jira/browse/NET-362
 Project: Commons Net
  Issue Type: Bug
Reporter: Sebb


The run() method references several variables shared with other threads, but 
does not use synch. or volatile
For example

__threaded
__isClosed

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (NET-348) Queue is full TelnetInputStream

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved NET-348.
--

Resolution: Fixed

Thanks for the report.

Fixed by moving the "__threaded = true;" statement to the thread run() method, 
so it will be set when the thread actually starts.

> Queue is full TelnetInputStream
> ---
>
> Key: NET-348
> URL: https://issues.apache.org/jira/browse/NET-348
> Project: Commons Net
>  Issue Type: Bug
>  Components: Telnet
>Affects Versions: 1.4
> Environment: Windows XP, Java JRE 1.6 
>Reporter: Krishnan Sivaramakrishna Iyer
>
> Hello 
>   I am using Telnet library of common.net. And I got an exception 
> in TelnetInputStream once in a while. 
>  
> The exception message was as following.
> 
> 
> Exception in thread "Thread-9399" java.lang.IllegalStateException: Queue
> is full! Cannot process another character.
> at
> org.apache.commons.net.telnet.TelnetInputStream.__processChar(TelnetInpu
> tStream.java:306)
> at
> org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.ja
> va:596)
> at java.lang.Thread.run(Thread.java:619)
> 
> 
>  
> At first, I think it is possible that I didn't call read() in time to
> read the data in TelnetInputStream so that the buffer
> of TelnetInputStream overflowed. But then I wrote a simple program to
> test it and I found that it is not the cause.
>  
> Then I studied the source of TelnetInputStream. The segment of function
> __processChar is as following.
> 280
>  InputStream.html#280>  private void __processChar(int ch) throws
> InterruptedException
> 281
>  InputStream.html#281>  {
> 282
>  InputStream.html#282>  // Critical section because we're
> altering __bytesAvailable,
> 283
>  InputStream.html#283>  // __queueTail, and the contents of
> _queue.
> 284
>  InputStream.html#284>  synchronized (__queue)
> 285
>  InputStream.html#285>  {
> 286
>  InputStream.html#286>  while (__bytesAvailable >=
> __queue.length - 1)
> 287
>  InputStream.html#287>  {
> 288
>  InputStream.html#288>  // The queue is full. We need to
> wait before adding any more data to it. Hopefully the stream owner
> 289
>  InputStream.html#289>  // will consume some data soon! 
> 290
>  InputStream.html#290>  if(__threaded)
> 291
>  InputStream.html#291>  {
> 292
>  InputStream.html#292>  __queue.notify();
> 293
>  InputStream.html#293>  try
> 294
>  InputStream.html#294>  {
> 295
>  InputStream.html#295>  __queue.wait();
> 296
>  InputStream.html#296>  }
> 297
>  InputStream.html#297>  catch (InterruptedException
> e)
> 298
>  InputStream.html#298>  {
> 299
>  InputStream.html#299>  throw e;
> 300
>  InputStream.html#300>  }
> 301
> 

[jira] Resolved: (NET-361) Implement Telnet Command sender

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NET-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved NET-361.
--

Resolution: Fixed
  Assignee: (was: Sebb)

> 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
>
> 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-258) Implement A Keepalive Mechanism

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001972#comment-13001972
 ] 

Sebb commented on NET-258:
--

Thanks!

Just for the record, I did initial testing against Apache MINA ftpserver 1.0.5 
and FileZilla server 0.9.37 beta installed locally.

FileZilla allows concurrent control and data, but ftpserver does not (but then 
most public ftp servers don't seem to either).

So luckily I was able to test both types quite easily during development.

I have also tried against several ASF ftp mirrors, and they seem to work.

What I have not been able to test is whether the NOOPs keep routers happy, 
because my router does not seem to cause any problems - I'm not sure it has a 
connection timeout feature.


If you do have access to such a router, the FTPClientExample class can be used 
to test if the keepalive helps.



> 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] Commented: (NET-258) Implement A Keepalive Mechanism

[Bogdan Drozdowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001955#comment-13001955
 ] 

Bogdan Drozdowski commented on NET-258:
---

Quite a change, I must say. If the timeouts are set correctly by the user, 
looks fine to me (should work; no obvious problems spotted). Nice work!

> 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: (CONFIGURATION-440) setProperty in XmlConfiguration escapes backslashes

[B (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

B updated CONFIGURATION-440:


Description: 
When setPropery sets a new value that has backslashes (like path), backslashes 
are escaped. When that value is loaded again, all backslashes are duplicated. 

Following test keeps failing. Don't know if there is some kind of formatting.

public class XmlConfigurationTest {

private static final String XML_CONFIGURATION_PATH = 
"resources/xml/config.xml";

private static final String PATH1 = "c:\\temp\\path\\file.txt";

private static final String PATH2 = "c:\\temp1\\path1\\file1.txt";

private static final String PATH3 = "c:\\temp2\\path2\\file2.txt";

@Test
public void testXmlConfiguration() throws IOException {
File resourceFile = null;
try {

assertNotNull(_bundleContext);
resourceFile = new File(SystemUtils.getTargetDirectory(),
XML_CONFIGURATION_PATH);
assertTrue(resourceFile.getParentFile().mkdirs());

String value = null;

XMLConfiguration configuration = new XMLConfiguration();
configuration.setExpressionEngine(new XPathExpressionEngine());
configuration.setDelimiterParsingDisabled(true);
configuration.addProperty(" key1", PATH1);
configuration.setProperty(" key2", PATH2);
configuration.save(resourceFile);
/* All values are saved with non escaped backslashes */

value = configuration.getString("key1");
assertEquals(value, PATH1);
value = configuration.getString("key2");
assertEquals(value, PATH2);

/*
 * Set again same property with different value. Setting property
 * with this configuration will escape backslashes. Even though
 * assert will pass, path with escaped backslashes will be written
 * in a file (don't know if it is setProperty or save that is 
causing troubles).
 */
configuration.setProperty(" key2", PATH3);
configuration.save(resourceFile);
value = configuration.getString("key2");
assertEquals(value, PATH3);

/*
 * Create new configuration and load values from previously saved
 * file.
 */
XMLConfiguration newConfiguration = new XMLConfiguration();
newConfiguration.setExpressionEngine(new XPathExpressionEngine());
newConfiguration.setDelimiterParsingDisabled(true);
newConfiguration.load(resourceFile);

/*
 * At this point, configuration will load escaped backslashes, and
 * the test will fail.
 */
value = newConfiguration.getString("key2");
assertEquals(value, PATH3);

} catch (Throwable e) {
e.printStackTrace();
fail(e.getLocalizedMessage());
} finally {
/*
 * Delete resource file
 */
resourceFile.delete();
}

}
}

  was:
When setPropery sets a new value that has backslashes (like path), backslashes 
are escaped. When that value is loaded again, all backslashes are duplicated. 

public class XmlConfigurationTest {

private static final String XML_CONFIGURATION_PATH = 
"resources/xml/config.xml";

private static final String PATH1 = "c:\\temp\\path\\file.txt";

private static final String PATH2 = "c:\\temp1\\path1\\file1.txt";

private static final String PATH3 = "c:\\temp2\\path2\\file2.txt";

@Test
public void testXmlConfiguration() throws IOException {
File resourceFile = null;
try {

assertNotNull(_bundleContext);
resourceFile = new File(SystemUtils.getTargetDirectory(),
XML_CONFIGURATION_PATH);
assertTrue(resourceFile.getParentFile().mkdirs());

String value = null;

XMLConfiguration configuration = new XMLConfiguration();
configuration.setExpressionEngine(new XPathExpressionEngine());
configuration.setDelimiterParsingDisabled(true);
configuration.addProperty(" key1", PATH1);
configuration.setProperty(" key2", PATH2);
configuration.save(resourceFile);
/* All values are saved with non escaped backslashes */

value = configuration.getString("key1");
assertEquals(value, PATH1);
value = configuration.getString("key2");
assertEquals(value, PATH2);

/*
 * Set again same property with different value. Setting property
 * with this configuration will escape backslashes. Even though
 * assert will pass, path with escaped backslashes will be written
 * in a file (don't k

[jira] Created: (CONFIGURATION-440) setProperty in XmlConfiguration escapes backslashes

[B (JIRA)]

setProperty in XmlConfiguration escapes backslashes
---

 Key: CONFIGURATION-440
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-440
 Project: Commons Configuration
  Issue Type: Bug
  Components: Build
Affects Versions: 1.6
 Environment: Windows 7
Reporter: B
 Fix For: 2.0


When setPropery sets a new value that has backslashes (like path), backslashes 
are escaped. When that value is loaded again, all backslashes are duplicated. 

public class XmlConfigurationTest {

private static final String XML_CONFIGURATION_PATH = 
"resources/xml/config.xml";

private static final String PATH1 = "c:\\temp\\path\\file.txt";

private static final String PATH2 = "c:\\temp1\\path1\\file1.txt";

private static final String PATH3 = "c:\\temp2\\path2\\file2.txt";

@Test
public void testXmlConfiguration() throws IOException {
File resourceFile = null;
try {

assertNotNull(_bundleContext);
resourceFile = new File(SystemUtils.getTargetDirectory(),
XML_CONFIGURATION_PATH);
assertTrue(resourceFile.getParentFile().mkdirs());

String value = null;

XMLConfiguration configuration = new XMLConfiguration();
configuration.setExpressionEngine(new XPathExpressionEngine());
configuration.setDelimiterParsingDisabled(true);
configuration.addProperty(" key1", PATH1);
configuration.setProperty(" key2", PATH2);
configuration.save(resourceFile);
/* All values are saved with non escaped backslashes */

value = configuration.getString("key1");
assertEquals(value, PATH1);
value = configuration.getString("key2");
assertEquals(value, PATH2);

/*
 * Set again same property with different value. Setting property
 * with this configuration will escape backslashes. Even though
 * assert will pass, path with escaped backslashes will be written
 * in a file (don't know if it is setProperty or save that is 
causing troubles).
 */
configuration.setProperty(" key2", PATH3);
configuration.save(resourceFile);
value = configuration.getString("key2");
assertEquals(value, PATH3);

/*
 * Create new configuration and load values from previously saved
 * file.
 */
XMLConfiguration newConfiguration = new XMLConfiguration();
newConfiguration.setExpressionEngine(new XPathExpressionEngine());
newConfiguration.setDelimiterParsingDisabled(true);
newConfiguration.load(resourceFile);

/*
 * At this point, configuration will load escaped backslashes, and
 * the test will fail.
 */
value = newConfiguration.getString("key2");
assertEquals(value, PATH3);

} catch (Throwable e) {
e.printStackTrace();
fail(e.getLocalizedMessage());
} finally {
/*
 * Delete resource file
 */
resourceFile.delete();
}

}
}

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira