[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239465#comment-16239465
]
ASF GitHub Bot commented on IO-554:
---
GitHub user mmariotti opened a pull request:
https://github.com/apache/commons-io/pull/49
[IO-554] fixed: prevent input stream close
[IO-554] FileUtils.copyToFile(InputStream source, File destination) closes
input stream.
Fixed removing 'source' from try-with-resources.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mmariotti/commons-io patch-1
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-io/pull/49.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 #49
commit c9fb10f0e45ec66cff342692fd440d06da250e88
Author: Michele Mariotti
Date: 2017-11-05T09:32:16Z
[IO-554] fixed: prevent input stream close
[IO-554] FileUtils.copyToFile(InputStream source, File destination) closes
input stream.
Fixed removing 'source' from try-with-resources.
> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239466#comment-16239466
]
Michele Mariotti commented on IO-554:
-
Created Pull Request [#49|https://github.com/apache/commons-io/pull/49].
Glad to help :)
> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239471#comment-16239471
]
Bernd Eckenfels commented on IO-554:
Can you add a test case as well?
> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239495#comment-16239495
]
Michele Mariotti commented on IO-554:
-
test case added
> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239524#comment-16239524
]
Christophe Schmaltz commented on COLLECTIONS-663:
-
Than you for your response.
I once used the {{MapIterator}}, sadly I found out that it doesn't support what
I try to achieve:
{code} @Test
public void testWhatINeedToWork() {
// ArrayListValuedHashMap multiMap = new
ArrayListValuedHashMap<>();
MultiValuedMap multiMap = new
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(1, 11);
multiMap.put(2, 20);
Iterator it = multiMap.mapIterator();
for (MapIterator iterator =
multiMap.mapIterator(); iterator.hasNext();) {
iterator.next();
Integer value = iterator.getValue();
if ((value % 2) == 0) {
// Integer is immutable, we need to replace
using setValue(.)
iterator.setValue(value * 2);
}
}
}{code}
My issue was that {{MapIterator.setValue(.)}} is not supported.
(My current workaround is storing the elements I need to change in a list, and
pushing them back in the map afterwards)
I understand the difficulty in implementing it for {{HashSetValuedHashMap}}
though, as the {{HashSet.iterator}} doesn't support it either (sadly, that's
what I need).
I observed that {{ArrayListValuedHashMap}} doesn't support {{setValue(.)}}
either (should be possible, as {{ArrayList.listIterator}} has this feature.
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239524#comment-16239524
]
Christophe Schmaltz edited comment on COLLECTIONS-663 at 11/5/17 1:20 PM:
--
Thank you for your response.
I once used the {{MapIterator}}, sadly I found out that it doesn't support what
I try to achieve:
{code} @Test
public void testWhatINeedToWork() {
// ArrayListValuedHashMap multiMap = new
ArrayListValuedHashMap<>();
MultiValuedMap multiMap = new
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(1, 11);
multiMap.put(2, 20);
Iterator it = multiMap.mapIterator();
for (MapIterator iterator =
multiMap.mapIterator(); iterator.hasNext();) {
iterator.next();
Integer value = iterator.getValue();
if ((value % 2) == 0) {
// Integer is immutable, we need to replace
using setValue(.)
iterator.setValue(value * 2);
}
}
}{code}
My issue was that {{MapIterator.setValue(.)}} is not supported.
(My current workaround is storing the elements I need to change in a list, and
pushing them back in the map afterwards)
I understand the difficulty in implementing it for {{HashSetValuedHashMap}}
though, as the {{HashSet.iterator}} doesn't support it either (sadly, that's
what I need).
I observed that {{ArrayListValuedHashMap}} doesn't support {{setValue(.)}}
either (should be possible, as {{ArrayList.listIterator}} has this feature.
was (Author: chris333):
Than you for your response.
I once used the {{MapIterator}}, sadly I found out that it doesn't support what
I try to achieve:
{code} @Test
public void testWhatINeedToWork() {
// ArrayListValuedHashMap multiMap = new
ArrayListValuedHashMap<>();
MultiValuedMap multiMap = new
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(1, 11);
multiMap.put(2, 20);
Iterator it = multiMap.mapIterator();
for (MapIterator iterator =
multiMap.mapIterator(); iterator.hasNext();) {
iterator.next();
Integer value = iterator.getValue();
if ((value % 2) == 0) {
// Integer is immutable, we need to replace
using setValue(.)
iterator.setValue(value * 2);
}
}
}{code}
My issue was that {{MapIterator.setValue(.)}} is not supported.
(My current workaround is storing the elements I need to change in a list, and
pushing them back in the map afterwards)
I understand the difficulty in implementing it for {{HashSetValuedHashMap}}
though, as the {{HashSet.iterator}} doesn't support it either (sadly, that's
what I need).
I observed that {{ArrayListValuedHashMap}} doesn't support {{setValue(.)}}
either (should be possible, as {{ArrayList.listIterator}} has this feature.
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239579#comment-16239579
]
Jochen Wiedmann commented on IO-554:
For the sake of binary compatibility, I'd suggest an alternate proposal:
- Change the Javadocs of FileUtils.copyToFile to reflect the current situation.
- Introduce a new method copyToFile(InputStream, File, boolean), which is
basically doing the same than the old implementation, except that the last
parameter decides upon closing, or not.
> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239595#comment-16239595
]
Michele Mariotti commented on IO-554:
-
There is already a method which closes the input stream: it is
FileUtils.copyInputStreamToFile.
The only difference between methods is the closure of input stream.
However, I agree that the method names are an unhappy choice and that should be
renamed to something more meaningful.
> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239738#comment-16239738
]
Bruno P. Kinoshita commented on IO-554:
---
[~joc...@apache.org]
>For the sake of binary compatibility, I'd suggest an alternate proposal
I think the change is still binary compatible, but not API/behavioral
compatible? Though I always get confused with these two...
As it seems like a bug/regression added accidentally in 2.6, I thought it could
still be fixed as in the pull request, and released in a 2.7 version. What do
you think?
> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LANG-1366) Add Feature for No ClassName and MultiLine StringStyle
[ https://issues.apache.org/jira/browse/LANG-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239794#comment-16239794 ] Karthikeyan Palanivelu commented on LANG-1366: -- Would like to contribute as I created for my internal project. Please Advise > Add Feature for No ClassName and MultiLine StringStyle > -- > > Key: LANG-1366 > URL: https://issues.apache.org/jira/browse/LANG-1366 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Karthikeyan Palanivelu > Labels: features > > Add feature to print String with No Class Name and MultiLine. This would be > of helpful for more like metrics related use cases which needs to print like > properties with No Class Name and each property in new line. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (LANG-1366) Add Feature for No ClassName and MultiLine StringStyle
Karthikeyan Palanivelu created LANG-1366: Summary: Add Feature for No ClassName and MultiLine StringStyle Key: LANG-1366 URL: https://issues.apache.org/jira/browse/LANG-1366 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Karthikeyan Palanivelu Add feature to print String with No Class Name and MultiLine. This would be of helpful for more like metrics related use cases which needs to print like properties with No Class Name and each property in new line. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239856#comment-16239856
]
Bruno P. Kinoshita commented on COLLECTIONS-663:
Oh, not sure if there's a better way. Got what I think is your desired result
with a not very elegant code.
{code:java}
public void testWhatINeedToWork() {
// ArrayListValuedHashMap multiMap = new
ArrayListValuedHashMap<>();
MultiValuedMap multiMap = new
HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(1, 11);
multiMap.put(2, 20);
MapIterator it = multiMap.mapIterator();
while (it.hasNext()) {
Integer key = it.next();
if (key % 2 == 0) {
Collection values = multiMap.get(key);
multiMap.putAll(key * 2, values);
it.remove();
}
}
}
{code}
> Unexpected ConcurrentModificationException when altering Collection of a
> MultiValuedMap
> ---
>
> Key: COLLECTIONS-663
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-663
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Christophe Schmaltz
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
>
> Testcase:
> {code}@Test
> public void test() {
> MultiValuedMap multiMap = new
> HashSetValuedHashMap<>();
> multiMap.put(1, 10);
> multiMap.put(2, 20);
> for (Collection innerCollection :
> multiMap.asMap().values()) {
> for (Iterator iterator =
> innerCollection.iterator(); iterator.hasNext();) {
> Integer i = iterator.next();
> iterator.remove(); // only the innerCollection
> is altered
> }
> // innerCollection.add(6); // adding stuff back should
> also work...
> }
> }{code}
> This test unexpectedly throws a ConcurrentModificationException.
> The issue is that when calling {{iterator.remove()}} the
> {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is
> empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.
> It may be better if the iterator of the inner collection had a reference on
> the iterator if the outer map and called {{containerIterator.remove()}}
> instead.
> *Note:* this solution would again present issues if the user tries to add new
> elements in this now empty collection (which was removed from the parent).
> In the current state, it is quite unclear why an exception is thrown, without
> debugging the code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-599) HashEntry array object naming data initialized with double the size during deserialization
[
https://issues.apache.org/jira/browse/COLLECTIONS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239959#comment-16239959
]
mingleizhang commented on COLLECTIONS-599:
--
Does anyone give me a permission that can contribute code to apache/commons ?
Thank you very much! Minglei.
> HashEntry array object naming data initialized with double the size during
> deserialization
> --
>
> Key: COLLECTIONS-599
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-599
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 3.1
>Reporter: Tejas Patel
>Priority: Critical
> Fix For: 4.1
>
>
> Common collections 3.1 and 3.2 are used at many places and frameworks
> including struts2.
> Supose a LinkedMap object it is created and have size greater than zero is
> serialized. While deserializing this object , array of HashEntry naming data
> delacred in AbstractHashedMap always initialises with a new capacity of
> double its double of the serialized object.
> Please see the below API declared in AbstractHashedMap class :
> protected void checkCapacity()
> {
> if (this.size >= this.threshold)
> {
> int newCapacity = this.data.length * 2;
> if (newCapacity <= 1073741824) {
> ensureCapacity(newCapacity);
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-659) make PassiveExpiringMap use clock
[ https://issues.apache.org/jira/browse/COLLECTIONS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239963#comment-16239963 ] mingleizhang commented on COLLECTIONS-659: -- Does anyone give me a permission that can contribute code to Collections ? Thanks in advance. > make PassiveExpiringMap use clock > - > > Key: COLLECTIONS-659 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-659 > Project: Commons Collections > Issue Type: Task >Reporter: Amir Behnam > > PassiveExpiringMap should use clocks to make it easier to test and interact > with. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-659) make PassiveExpiringMap use clock
[
https://issues.apache.org/jira/browse/COLLECTIONS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239968#comment-16239968
]
mingleizhang commented on COLLECTIONS-659:
--
Hi, [~amir20001] What you mean is that we should add a clock to some method
like in {{public void clear()}}, {{public boolean containsKey}} or {{public V
get(final Object key)}} in {{PassiveExpiringMap}} file ?
> make PassiveExpiringMap use clock
> -
>
> Key: COLLECTIONS-659
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-659
> Project: Commons Collections
> Issue Type: Task
>Reporter: Amir Behnam
>
> PassiveExpiringMap should use clocks to make it easier to test and interact
> with.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CONFIGURATION-674) Add class FileProperties to load file name directly
mingleizhang created CONFIGURATION-674: -- Summary: Add class FileProperties to load file name directly Key: CONFIGURATION-674 URL: https://issues.apache.org/jira/browse/CONFIGURATION-674 Project: Commons Configuration Issue Type: New Feature Components: File reloading Reporter: mingleizhang -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CONFIGURATION-674) Add class FileProperties to load file name directly
[
https://issues.apache.org/jira/browse/CONFIGURATION-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mingleizhang updated CONFIGURATION-674:
---
Description: For example, In some interface, needs we have a
{{java.util.Properties}} as a parameter. In common case, we have different
profiles in maven under different environments that we can random selection.
And use the current classloader, usually belongs to AppclassLoader to get it's
inputstream. I propose we should add a functionality that can directly read a
file name and return a {{java.util.Properties}} as a return value.
> Add class FileProperties to load file name directly
> ---
>
> Key: CONFIGURATION-674
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-674
> Project: Commons Configuration
> Issue Type: New Feature
> Components: File reloading
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a
> parameter. In common case, we have different profiles in maven under
> different environments that we can random selection. And use the current
> classloader, usually belongs to AppclassLoader to get it's inputstream. I
> propose we should add a functionality that can directly read a file name and
> return a {{java.util.Properties}} as a return value.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CONFIGURATION-675) Add .gitignore file
mingleizhang created CONFIGURATION-675: -- Summary: Add .gitignore file Key: CONFIGURATION-675 URL: https://issues.apache.org/jira/browse/CONFIGURATION-675 Project: Commons Configuration Issue Type: Improvement Components: Build Reporter: mingleizhang Priority: Blocker Add .gitignore to this project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream
[
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240010#comment-16240010
]
Jochen Wiedmann commented on IO-554:
Fact is, if we pull that one in, then the next version will behave different,
which makes it binary incompatible. Perhaps, a discussion on devs@commons is in
order.
> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
> Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
> * Copies bytes from an {@link InputStream} source to a file
> * destination. The directories up to destination
> * will be created if they don't already exist. destination
> * will be overwritten if it already exists.
> * The {@code source} stream is left open, e.g. for use with {@link
> java.util.zip.ZipInputStream ZipInputStream}.
> * See {@link #copyInputStreamToFile(InputStream, File)} for a method that
> closes the input stream.
> *
> * @param source the InputStream to copy bytes from, must
> not be {@code null}
> * @param destination the non-directory File to write bytes to
> *(possibly overwriting), must not be {@code null}
> * @throws IOException if destination is a directory
> * @throws IOException if destination cannot be written
> * @throws IOException if destination needs creating but can't be
> * @throws IOException if an IO error occurs during copying
> * @since 2.5
> */
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(in, out);
> }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File
> destination) throws IOException {
> try (OutputStream out = openOutputStream(destination)) {
> IOUtils.copy(source, out);
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
