[jira] Created: (CONFIGURATION-440) setProperty in XmlConfiguration escapes backslashes
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
[jira] Updated: (CONFIGURATION-440) setProperty in XmlConfiguration escapes backslashes
[
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 know if it is setProperty or save that
[jira] Commented: (NET-258) Implement A Keepalive Mechanism
[ https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Commented: (NET-258) Implement A Keepalive Mechanism
[ https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Resolved: (NET-361) Implement Telnet Command sender
[ 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] Resolved: (NET-348) Queue is full TelnetInputStream
[
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
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#280 private void __processChar(int ch) throws
InterruptedException
281
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#281 {
282
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#282 // Critical section because we're
altering __bytesAvailable,
283
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#283 // __queueTail, and the contents of
_queue.
284
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#284 synchronized (__queue)
285
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#285 {
286
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#286 while (__bytesAvailable =
__queue.length - 1)
287
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#287 {
288
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#288 // The queue is full. We need to
wait before adding any more data to it. Hopefully the stream owner
289
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#289 // will consume some data soon!
290
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#290 if(__threaded)
291
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#291 {
292
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#292 __queue.notify();
293
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#293 try
294
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#294 {
295
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#295 __queue.wait();
296
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#296 }
297
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#297 catch (InterruptedException
e)
298
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#298 {
299
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#299 throw e;
300
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#300 }
301
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#301 }
302
http://commons.apache.org/net/xref/org/apache/commons/net/telnet/Telnet
InputStream.html#302
[jira] Created: (NET-362) TelnetInputStream has various threading bugs
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] Closed: (MATH-535) Closing the loop in function objects
[
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] 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
]
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
[
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
[
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 value IAC SE}} to the client; to set the
serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
value(4) 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: (LANG-679) StringUtils.startsWithIgnoreCase whrong documentation
[ https://issues.apache.org/jira/browse/LANG-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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 value IAC SE}} to the client; to set the
serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
value(4) 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
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: (NET-344) Telnet client: Support Listener Notification of Incoming Data
[
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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
]
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-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:comment-tabpanelfocusedCommentId=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
[
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
[
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] Updated: (NET-344) Telnet client: Support Listener Notification of Incoming Data
[
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] Commented: (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:comment-tabpanelfocusedCommentId=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] Resolved: (LANG-679) StringUtils.startsWithIgnoreCase whrong documentation
[ 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] Created: (LANG-682) Public constants on StringEscapeUtils do not have javadoc
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] Created: (LANG-683) The StringUtils.concat methods duplicate the existing join methods
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] Updated: (LANG-682) Public constants on StringEscapeUtils do not have javadoc
[ 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
