[GitHub] commons-io pull request #55: IO-568: AutoCloseInputStream crash on reset() w...
GitHub user tmortagne opened a pull request: https://github.com/apache/commons-io/pull/55 IO-568: AutoCloseInputStream crash on reset() when reading the whole stream You can merge this pull request into a Git repository by running: $ git pull https://github.com/tmortagne/commons-io IO-568 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-io/pull/55.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #55 commit 7c042b8d677ee3019de72e7e5c34c4d78d375ef9 Author: Thomas Mortagne Date: 2018-02-07T10:04:53Z IO-568: AutoCloseInputStream crash on reset() when reading the whole stream --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1823550 - in /commons/proper/net/trunk/src: changes/changes.xml main/java/org/apache/commons/net/telnet/TelnetClient.java
Hi.
On Thu, 08 Feb 2018 11:55:10 -, s...@apache.org wrote:
Author: sebb
Date: Thu Feb 8 11:55:10 2018
New Revision: 1823550
URL: http://svn.apache.org/viewvc?rev=1823550&view=rev
Log:
NET-643 NPE when closing telnet stream
[...]
Modified:
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
URL:
http://svn.apache.org/viewvc/commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java?rev=1823550&r1=1823549&r2=1823550&view=diff
==
---
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
(original)
+++
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
Thu Feb 8 11:55:10 2018
@@ -100,10 +100,16 @@ public class TelnetClient extends Telnet
void _flushOutputStream() throws IOException
{
+if (_output_ == null) {
+throw new IOException("Stream closed");
+}
_output_.flush();
}
void _closeOutputStream() throws IOException
{
+if (_output_ == null) {
+return;
+}
try {
_output_.close();
} finally {
Why the difference in behaviour?
In the former case, "no-op" seems equally fine.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1823550 - in /commons/proper/net/trunk/src: changes/changes.xml main/java/org/apache/commons/net/telnet/TelnetClient.java
On 8 February 2018 at 12:08, Gilles wrote:
> Hi.
>
> On Thu, 08 Feb 2018 11:55:10 -, s...@apache.org wrote:
>>
>> Author: sebb
>> Date: Thu Feb 8 11:55:10 2018
>> New Revision: 1823550
>>
>> URL: http://svn.apache.org/viewvc?rev=1823550&view=rev
>> Log:
>> NET-643 NPE when closing telnet stream
>>
>> [...]
>>
>> Modified:
>>
>>
>> commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
>> URL:
>>
>>
>> http://svn.apache.org/viewvc/commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java?rev=1823550&r1=1823549&r2=1823550&view=diff
>>
>>
>> ==
>> ---
>>
>>
>> commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
>> (original)
>> +++
>>
>>
>> commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
>> Thu Feb 8 11:55:10 2018
>> @@ -100,10 +100,16 @@ public class TelnetClient extends Telnet
>>
>> void _flushOutputStream() throws IOException
>> {
>> +if (_output_ == null) {
>> +throw new IOException("Stream closed");
>> +}
>> _output_.flush();
>> }
>> void _closeOutputStream() throws IOException
>> {
>> +if (_output_ == null) {
>> +return;
>> +}
>> try {
>> _output_.close();
>> } finally {
>
>
> Why the difference in behaviour?
See NET-643
close() is supposed to be idempotent; flush() is not supposed to be
called on a closed stream.
> In the former case, "no-op" seems equally fine.
It was not a no-op; it was NPE.
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1823550 - in /commons/proper/net/trunk/src: changes/changes.xml main/java/org/apache/commons/net/telnet/TelnetClient.java
On Thu, 8 Feb 2018 12:42:55 +, sebb wrote:
On 8 February 2018 at 12:08, Gilles
wrote:
Hi.
On Thu, 08 Feb 2018 11:55:10 -, s...@apache.org wrote:
Author: sebb
Date: Thu Feb 8 11:55:10 2018
New Revision: 1823550
URL: http://svn.apache.org/viewvc?rev=1823550&view=rev
Log:
NET-643 NPE when closing telnet stream
[...]
Modified:
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
URL:
http://svn.apache.org/viewvc/commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java?rev=1823550&r1=1823549&r2=1823550&view=diff
==
---
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
(original)
+++
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
Thu Feb 8 11:55:10 2018
@@ -100,10 +100,16 @@ public class TelnetClient extends Telnet
void _flushOutputStream() throws IOException
{
+if (_output_ == null) {
+throw new IOException("Stream closed");
+}
_output_.flush();
}
void _closeOutputStream() throws IOException
{
+if (_output_ == null) {
+return;
+}
try {
_output_.close();
} finally {
Why the difference in behaviour?
See NET-643
I did, before writing my first reply.
close() is supposed to be idempotent; flush() is not supposed to be
called on a closed stream.
No such requirement here:
https://docs.oracle.com/javase/8/docs/api/java/io/OutputStream.html#flush--
In the former case, "no-op" seems equally fine.
It was not a no-op; it was NPE.
In the commit which I referred to, you added a "no-op" for
"close()" and my comment is that the same can be done for
"flush()" in the same circumstance (ie. no-op when "_output_"
is null).
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1823550 - in /commons/proper/net/trunk/src: changes/changes.xml main/java/org/apache/commons/net/telnet/TelnetClient.java
On 8 February 2018 at 12:54, Gilles wrote:
> On Thu, 8 Feb 2018 12:42:55 +, sebb wrote:
>>
>> On 8 February 2018 at 12:08, Gilles wrote:
>>>
>>> Hi.
>>>
>>> On Thu, 08 Feb 2018 11:55:10 -, s...@apache.org wrote:
Author: sebb
Date: Thu Feb 8 11:55:10 2018
New Revision: 1823550
URL: http://svn.apache.org/viewvc?rev=1823550&view=rev
Log:
NET-643 NPE when closing telnet stream
[...]
Modified:
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
URL:
http://svn.apache.org/viewvc/commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java?rev=1823550&r1=1823549&r2=1823550&view=diff
==
---
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
(original)
+++
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
Thu Feb 8 11:55:10 2018
@@ -100,10 +100,16 @@ public class TelnetClient extends Telnet
void _flushOutputStream() throws IOException
{
+if (_output_ == null) {
+throw new IOException("Stream closed");
+}
_output_.flush();
}
void _closeOutputStream() throws IOException
{
+if (_output_ == null) {
+return;
+}
try {
_output_.close();
} finally {
>>>
>>>
>>>
>>> Why the difference in behaviour?
>>
>>
>> See NET-643
>
>
> I did, before writing my first reply.
>
>> close() is supposed to be idempotent; flush() is not supposed to be
>> called on a closed stream.
>
>
> No such requirement here:
> https://docs.oracle.com/javase/8/docs/api/java/io/OutputStream.html#flush--
I was going by the Javadoc here:
https://docs.oracle.com/javase/8/docs/api/java/io/OutputStreamWriter.html#close--
It seems to me that ignoring flush is not the right thing to do.
>>> In the former case, "no-op" seems equally fine.
>>
>>
>> It was not a no-op; it was NPE.
>
>
> In the commit which I referred to, you added a "no-op" for
> "close()" and my comment is that the same can be done for
> "flush()" in the same circumstance (ie. no-op when "_output_"
> is null).
>
>
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1823550 - in /commons/proper/net/trunk/src: changes/changes.xml main/java/org/apache/commons/net/telnet/TelnetClient.java
On Thu, 8 Feb 2018 13:26:25 +, sebb wrote:
On 8 February 2018 at 12:54, Gilles
wrote:
On Thu, 8 Feb 2018 12:42:55 +, sebb wrote:
On 8 February 2018 at 12:08, Gilles
wrote:
Hi.
On Thu, 08 Feb 2018 11:55:10 -, s...@apache.org wrote:
Author: sebb
Date: Thu Feb 8 11:55:10 2018
New Revision: 1823550
URL: http://svn.apache.org/viewvc?rev=1823550&view=rev
Log:
NET-643 NPE when closing telnet stream
[...]
Modified:
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
URL:
http://svn.apache.org/viewvc/commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java?rev=1823550&r1=1823549&r2=1823550&view=diff
==
---
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
(original)
+++
commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/TelnetClient.java
Thu Feb 8 11:55:10 2018
@@ -100,10 +100,16 @@ public class TelnetClient extends Telnet
void _flushOutputStream() throws IOException
{
+if (_output_ == null) {
+throw new IOException("Stream closed");
+}
_output_.flush();
}
void _closeOutputStream() throws IOException
{
+if (_output_ == null) {
+return;
+}
try {
_output_.close();
} finally {
Why the difference in behaviour?
See NET-643
I did, before writing my first reply.
close() is supposed to be idempotent; flush() is not supposed to be
called on a closed stream.
No such requirement here:
https://docs.oracle.com/javase/8/docs/api/java/io/OutputStream.html#flush--
I was going by the Javadoc here:
https://docs.oracle.com/javase/8/docs/api/java/io/OutputStreamWriter.html#close--
It seems to me that ignoring flush is not the right thing to do.
The doc which you refer to reads:
---CUT---
Closes the stream, flushing it first. Once the stream has been closed,
further write() or flush() invocations will cause an IOException to be
thrown. Closing a previously closed stream has no effect.
---CUT---
IIUC, the first means that, functionally, "close()" works as the
following sequence:
out.flush();
out.close();
However, if one does
out.close();
out.close();
it's fine, but
out.flush();
out.close();
out.flush();
out.close();
would throw IOException.
I don't understand how useful it is to make a difference between
two similar situations. [Calling "flush" after "close" with no
intervening "write" is asking to "transfer no data"; so no harm
done IMHO...]
Anyways, if the goal is to comply with the JDK "logic", no problem. :-)
Gilles
In the former case, "no-op" seems equally fine.
It was not a no-op; it was NPE.
In the commit which I referred to, you added a "no-op" for
"close()" and my comment is that the same can be done for
"flush()" in the same circumstance (ie. no-op when "_output_"
is null).
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[RNG] Travis build fails with JDK 9
Hi. Build succeeds with JDK 7 and 8 but not with JDK9: https://travis-ci.org/apache/commons-rng/jobs/337207823 Did someone encounter this problem? Regards, Gilles P.S. Build also fails locally (on Debian "stretch") with the same error: ---CUT--- [...] [ERROR] Error occurred in starting fork, check output in log [ERROR] Process Exit Code: 134 [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called? [...] ---CUT--- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RNG] Towards v1.1
Ping? On Fri, 26 Jan 2018 16:06:10 +0100, Gilles wrote: Hello. I propose to release the next version of "Commons RNG". The web site with the current (today) development version (to become 1.1) is on-line: http://commons.apache.org/rng Could someone please take on the following issue (JDK 9): https://issues.apache.org/jira/browse/RNG-40 and fix it if necessary (each maven "module" should be a "Java" module)? [I do not have Java 9 installed.] I've just installed it. See other post (with subject: "Travis build fails"). Is there a multi-module "Commons" project whose artefacts are known to work as Java 9 modules? I'd like to release v1.1 but I don't think it's worth pretending that it is Java 9 compatible without doing anything more than adding a MANIFEST entry (that could be wrong). I'd rather remove the "Automatic-Module-Name" and postpone issue RNG-40 to v1.2 (even if it would be the only change wrt v1.1). Regards, Gilles Other remarks, suggestions, blockers? Help is welcome for the release process using the new plugin developed by Rob (and, along the way, update the documentation located in the "doc/release" directory). Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Compress 1.16.1 based on RC1
On 2018-02-07, Stefan Bodewig wrote: > I've again managed to mess up the OSGi manifest with Compress 1.16 so > this is a quick bug fix release that doesn't contain any code changes. +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RNG] Travis build fails with JDK 9
On Thu, Feb 8, 2018 at 9:01 AM, Gilles wrote: > Hi. > > Build succeeds with JDK 7 and 8 but not with JDK9: > https://travis-ci.org/apache/commons-rng/jobs/337207823 > > Did someone encounter this problem? Taking a guess here: looking at line 3521 of the log [1], it looks like the symptom described in the surefire FAQ [2] about corrupted streamps. I don't know RNG code to comment, but maybe a quick check will be to try the build without forking (forkCount=0) or using a snapshot of surefire 2.21.0 [3], which seems to have a few more Java 9 goodies. Bindul [1] https://travis-ci.org/apache/commons-rng/jobs/337207823#L3521 [2] http://maven.apache.org/surefire/maven-surefire-plugin/faq.html#corruptedstream [3] https://issues.apache.org/jira/projects/SUREFIRE/versions/12341630 > > Regards, > Gilles > > P.S. Build also fails locally (on Debian "stretch") with the > same error: > ---CUT--- > [...] > [ERROR] Error occurred in starting fork, check output in log > [ERROR] Process Exit Code: 134 > [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The > forked VM terminated without properly saying goodbye. VM crash or > System.exit called? > [...] > ---CUT--- > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
