[GitHub] commons-lang issue #305: Remove unnecessary testing comments
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/305 [![Coverage Status](https://coveralls.io/builds/14043222/badge)](https://coveralls.io/builds/14043222) Coverage remained the same at 95.164% when pulling **c163de74ae7686a8f661d00ddcd7f85272ee7f9a on hquan:master** into **425d8085cfcaab5a78bf0632f9ae77b7e9127cf8 on apache:master**. ---
[GitHub] commons-lang pull request #305: Remove unnecessary testing comments
GitHub user hquan opened a pull request: https://github.com/apache/commons-lang/pull/305 Remove unnecessary testing comments You can merge this pull request into a Git repository by running: $ git pull https://github.com/hquan/commons-lang master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/305.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 #305 commit c163de74ae7686a8f661d00ddcd7f85272ee7f9a Author: Haoliang QuanDate: 2017-11-05T05:04:24Z Remove unnecessary testing comments ---
[jira] [Updated] (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:all-tabpanel ] Bruno P. Kinoshita updated IO-554: -- Assignee: Bruno P. Kinoshita > 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=16239364#comment-16239364 ] Bruno P. Kinoshita commented on IO-554: --- Nice catch [~mmariotti] Would you like to submit a pull request with this change? If not, let me know and I'll quickly prepare a pull request and credit you. Thanks Bruno > 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 >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=16239363#comment-16239363 ] Bruno P. Kinoshita commented on COLLECTIONS-663: I believe the Javadocs from asMap from MultiValuedMap indicate it works for as a view for a state in the collection. If you have to alter the map or the values collection, I'd try first using the mapIterator() method from the MultiValuedMap. It returns a custom iterator. The following altered code works for me: {code:java} public void testAlteringCollection() { MultiValuedMapmultiMap = new HashSetValuedHashMap<>(); multiMap.put(1, 10); multiMap.put(2, 20); Iterator it = multiMap.mapIterator(); for (Iterator iterator = multiMap.mapIterator(); iterator.hasNext();) { Integer i = iterator.next(); iterator.remove(); // only the innerCollection is altered } } {code} Does it help? Bruno > 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 >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] [Updated] (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:all-tabpanel ] Bruno P. Kinoshita updated COLLECTIONS-663: --- Assignee: Bruno P. Kinoshita > 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() { > MultiValuedMapmultiMap = 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] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239358#comment-16239358 ] ASF GitHub Bot commented on LANG-1339: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/275 >My suggestion would be to add two new classes with the fixed code (different class names), and deprecated the old classes. That way there is no need to have commons-lang v4. Thought a bit about that after seeing the vote for [lang] 3.7. In any way, the current implementation will be removed only in 4.x, and we will have to include the require static for Java 9 module. So right now I am thinking about not marking the class or fields as deprecated, nor adding another class with a different name. Just keep this PR and the ticket open. Then mark the ticket as FixVersion 4.0, use the require static trick for the module-info.java for Java 9. Does that sound like a good plan? > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter > Labels: Java9 > Fix For: 3.7 > > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang issue #275: [WIP] LANG-1339: replace java.beans.PropertyListene...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/275 >My suggestion would be to add two new classes with the fixed code (different class names), and deprecated the old classes. That way there is no need to have commons-lang v4. Thought a bit about that after seeing the vote for [lang] 3.7. In any way, the current implementation will be removed only in 4.x, and we will have to include the require static for Java 9 module. So right now I am thinking about not marking the class or fields as deprecated, nor adding another class with a different name. Just keep this PR and the ticket open. Then mark the ticket as FixVersion 4.0, use the require static trick for the module-info.java for Java 9. Does that sound like a good plan? ---
[jira] [Updated] (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:all-tabpanel ] Christophe Schmaltz updated COLLECTIONS-663: Description: Testcase: {code} @Test public void test() { MultiValuedMapmultiMap = 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. was: 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 } } }{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. > 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 > > 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] [Updated] (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:all-tabpanel ] Christophe Schmaltz updated COLLECTIONS-663: Description: Testcase: {code} @Test public void test() { MultiValuedMapmultiMap = 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 } } }{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. was: 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 } } }{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 would be better if the iterator of the inner collection had a reference on the iterator if the outer map and called {{containerIterator.remove()}} instead. In the current state, it is quite unclear why an exception is thrown, without debugging the 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 > > 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 > } > } > }{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] [Created] (COLLECTIONS-663) Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap
Christophe Schmaltz created COLLECTIONS-663: --- Summary: 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 Testcase: {code} @Test public void test() { MultiValuedMapmultiMap = 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 } } }{code} This test unexpectedly throws a ConcurrentModificationException. The issue is that when calling {{iterator.remove()}} the {{multimap.AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty and calls {{AbstractMultiValuedMap.this.remove(key);}}. It would be better if the iterator of the inner collection had a reference on the iterator if the outer map and called {{containerIterator.remove()}} instead. 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] [Updated] (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:all-tabpanel ] Christophe Schmaltz updated COLLECTIONS-663: Description: Testcase: {code} @Test public void test() { MultiValuedMapmultiMap = 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 } } }{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 would be better if the iterator of the inner collection had a reference on the iterator if the outer map and called {{containerIterator.remove()}} instead. In the current state, it is quite unclear why an exception is thrown, without debugging the code. was: 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 } } }{code} This test unexpectedly throws a ConcurrentModificationException. The issue is that when calling {{iterator.remove()}} the {{multimap.AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty and calls {{AbstractMultiValuedMap.this.remove(key);}}. It would be better if the iterator of the inner collection had a reference on the iterator if the outer map and called {{containerIterator.remove()}} instead. In the current state, it is quite unclear why an exception is thrown, without debugging the 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 > > 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 > } > } > }{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 would be better if the iterator of the inner collection had a reference on > the iterator if the outer map and called {{containerIterator.remove()}} > instead. > 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] [Closed] (POOL-332) ObjectPool and KeyedObject pool should extend Closeable
[ https://issues.apache.org/jira/browse/POOL-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed POOL-332. - Resolution: Fixed In Git master. There are still a small set of tests that could be cleaned up with try-with-resources blocks. > ObjectPool and KeyedObject pool should extend Closeable > --- > > Key: POOL-332 > URL: https://issues.apache.org/jira/browse/POOL-332 > Project: Commons Pool > Issue Type: New Feature >Reporter: Gary Gregory >Priority: Major > Fix For: 2.5 > > > {{ObjectPool}} and {{KeyedObject}} pool should extend {{java.io.Closeable}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (VFS-647) calling findFiles() causes copyFrom() to fail with a partially downloaded file.
[ https://issues.apache.org/jira/browse/VFS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239069#comment-16239069 ] Bernd Eckenfels edited comment on VFS-647 at 11/4/17 3:58 PM: -- The filesystems instance is the same when the parameter (incl options and base URL) are the same. This is part of how the caching works. (VFS.getManager() is a Singleton, but I removed that part of the comment as your code does not close it) was (Author: b.eckenfels): As I Said the filesystems instance is the same when the parameter (+options) are the same. > calling findFiles() causes copyFrom() to fail with a partially downloaded > file. > --- > > Key: VFS-647 > URL: https://issues.apache.org/jira/browse/VFS-647 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0, 2.2 > Environment: Windows 7 and Linux Red Hat. >Reporter: Kenji >Priority: Minor > > Edit: The problem isn't specific to findFiles. All I need to do is have 1 > thread downloads the file, and the other thread just log in, have a while > loop for x seconds where x < download time (using Thread.sleep(x) causes > interruption to happen immediately). Once x seconds passed, the download will > get interupted with pipe closed. Using the same hostname but different > username and password does not cause interruption. > Original description: > When using FileObject.copyFrom(remote, new AllFileSelector()) to download > file from remote to local directory. If SftpFileObject.findFiles(new > FileDepthSelector(1,1)) is called and finished, then the copyFrom will get > interrupted with error pipe closed. > Below are test codes and stack trace error. In real scenario, this all > happens within 1 or 2 second time frame. However, with test scenario, I > wasn't able to reproduce it easily therefore I had to choose a file that > takes around 10 seconds to download and have Thread.sleep(5000) after > findFiles() call. Only tested jsch-0.1.52, jsch-0.1.54, commons-vfs2-2.0 and > commons-vfs2-2.2. > {code:java} > public class FtpClient { > > public static void main(String[] args) { > if (args.length < 5) { > throw new RuntimeException("args: host user pass local > remote"); > } > String hostname = args[0]; > String username = args[1]; > String password = args[2]; > int port = 22; > String local = args[3]; > String remote = args[4]; > final String remoteDir = remote.substring(0, Math.max(0, > remote.lastIndexOf("/"))); > Thread t0 = new Thread() { > public void run() { > try (Ftp ftp = new Ftp(hostname, port)) { > ftp.login(username, password); > ftp.list(remoteDir); > System.out.println("findFiles() > completed."); > } catch (Exception e) { > e.printStackTrace(); > } > } > }; > > Thread ti = new Thread() { > public void run() { > try (Ftp ftp = new Ftp(hostname, port)) { > ftp.login(username, password); > ftp.download(local, remote); > } catch (Exception e) { > e.printStackTrace(); > } > } > }; > t0.start(); > ti.start(); > } > } > public class Ftp implements AutoCloseable { > private int timeout = 0; > private StaticUserAuthenticator userAuth; > private FileSystemOptions fileSysOpts; > private FileObject scr = null; > private FileSystemManager fsm = null; > private String hostName; > private int port = 0; > public Ftp(String remoteHost, int controlPort) throws > FileSystemException { > hostName = remoteHost; > port = controlPort; > fsm = VFS.getManager(); > } > //login into a server with a valid account > public void login(String user, String password) throws IOException { > userAuth = new StaticUserAuthenticator(null, user, password); > fileSysOpts = new FileSystemOptions(); > > DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fileSysOpts, > userAuth); > >
[jira] [Commented] (VFS-647) calling findFiles() causes copyFrom() to fail with a partially downloaded file.
[ https://issues.apache.org/jira/browse/VFS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239069#comment-16239069 ] Bernd Eckenfels commented on VFS-647: - As I Said the filesystems instance is the same when the parameter (+options) are the same. > calling findFiles() causes copyFrom() to fail with a partially downloaded > file. > --- > > Key: VFS-647 > URL: https://issues.apache.org/jira/browse/VFS-647 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0, 2.2 > Environment: Windows 7 and Linux Red Hat. >Reporter: Kenji >Priority: Minor > > Edit: The problem isn't specific to findFiles. All I need to do is have 1 > thread downloads the file, and the other thread just log in, have a while > loop for x seconds where x < download time (using Thread.sleep(x) causes > interruption to happen immediately). Once x seconds passed, the download will > get interupted with pipe closed. Using the same hostname but different > username and password does not cause interruption. > Original description: > When using FileObject.copyFrom(remote, new AllFileSelector()) to download > file from remote to local directory. If SftpFileObject.findFiles(new > FileDepthSelector(1,1)) is called and finished, then the copyFrom will get > interrupted with error pipe closed. > Below are test codes and stack trace error. In real scenario, this all > happens within 1 or 2 second time frame. However, with test scenario, I > wasn't able to reproduce it easily therefore I had to choose a file that > takes around 10 seconds to download and have Thread.sleep(5000) after > findFiles() call. Only tested jsch-0.1.52, jsch-0.1.54, commons-vfs2-2.0 and > commons-vfs2-2.2. > {code:java} > public class FtpClient { > > public static void main(String[] args) { > if (args.length < 5) { > throw new RuntimeException("args: host user pass local > remote"); > } > String hostname = args[0]; > String username = args[1]; > String password = args[2]; > int port = 22; > String local = args[3]; > String remote = args[4]; > final String remoteDir = remote.substring(0, Math.max(0, > remote.lastIndexOf("/"))); > Thread t0 = new Thread() { > public void run() { > try (Ftp ftp = new Ftp(hostname, port)) { > ftp.login(username, password); > ftp.list(remoteDir); > System.out.println("findFiles() > completed."); > } catch (Exception e) { > e.printStackTrace(); > } > } > }; > > Thread ti = new Thread() { > public void run() { > try (Ftp ftp = new Ftp(hostname, port)) { > ftp.login(username, password); > ftp.download(local, remote); > } catch (Exception e) { > e.printStackTrace(); > } > } > }; > t0.start(); > ti.start(); > } > } > public class Ftp implements AutoCloseable { > private int timeout = 0; > private StaticUserAuthenticator userAuth; > private FileSystemOptions fileSysOpts; > private FileObject scr = null; > private FileSystemManager fsm = null; > private String hostName; > private int port = 0; > public Ftp(String remoteHost, int controlPort) throws > FileSystemException { > hostName = remoteHost; > port = controlPort; > fsm = VFS.getManager(); > } > //login into a server with a valid account > public void login(String user, String password) throws IOException { > userAuth = new StaticUserAuthenticator(null, user, password); > fileSysOpts = new FileSystemOptions(); > > DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fileSysOpts, > userAuth); > > SftpFileSystemConfigBuilder.getInstance().setStrictHostKeyChecking(fileSysOpts, > "no"); > > SftpFileSystemConfigBuilder.getInstance().setTimeout(fileSysOpts, timeout); > > SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fileSysOpts, > false); > scr = (FileObject)fsm.resolveFile("sftp://; + hostName, > fileSysOpts); >
[jira] [Resolved] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale
[ https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved LANG-1362. - Resolution: Fixed Assignee: Gary Gregory > Fix tests DateUtilsTest for Java 9 with en_GB locale > > > Key: LANG-1362 > URL: https://issues.apache.org/jira/browse/LANG-1362 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* >Reporter: Stephen Colebourne >Assignee: Gary Gregory >Priority: Minor > Fix For: 3.7 > > > On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not > formatted as "MST". I'm unclear as to why this is, but it is not relevant to > what the test is trying to do. As such, I've changed the zone to > "America/Denver" and changed the format letter from "z" to "XXX" to make it > more reliable. > The PR also uses try-finally when setting the default time-zone to avoid > pollution of global state if a test fails (the pollution here made it look > like 8 test failures when there was only in fact 1). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang pull request #304: Fix DateUtilsTest to work reliably on Java 9
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/304 ---
[jira] [Commented] (LANG-1362) Fix tests DateUtilsTest for Java 9 with en_GB locale
[ https://issues.apache.org/jira/browse/LANG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239041#comment-16239041 ] ASF GitHub Bot commented on LANG-1362: -- Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/304 > Fix tests DateUtilsTest for Java 9 with en_GB locale > > > Key: LANG-1362 > URL: https://issues.apache.org/jira/browse/LANG-1362 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* >Reporter: Stephen Colebourne >Priority: Minor > Fix For: 3.7 > > > On Java 9 I see DateUtilsTest fail. This is because "MST7MDT" zone is not > formatted as "MST". I'm unclear as to why this is, but it is not relevant to > what the test is trying to do. As such, I've changed the zone to > "America/Denver" and changed the format letter from "z" to "XXX" to make it > more reliable. > The PR also uses try-finally when setting the default time-zone to avoid > pollution of global state if a test fails (the pollution here made it look > like 8 test failures when there was only in fact 1). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (BCEL-299) Can not resolve symbol code
[ https://issues.apache.org/jira/browse/BCEL-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238996#comment-16238996 ] ASF GitHub Bot commented on BCEL-299: - GitHub user zhangminglei opened a pull request: https://github.com/apache/commons-bcel/pull/21 [BCEL-299] Fix resolve symbol error You can merge this pull request into a Git repository by running: $ git pull https://github.com/zhangminglei/commons-bcel BCEL-299 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-bcel/pull/21.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 #21 commit 0f61c7c18f46d8bdb96e05b290baf629811ac6f1 Author: zhangmingleiDate: 2017-11-04T13:14:18Z [BCEL-299] Fix resolve symbol error > Can not resolve symbol code > --- > > Key: BCEL-299 > URL: https://issues.apache.org/jira/browse/BCEL-299 > Project: Commons BCEL > Issue Type: Bug >Reporter: mingleizhang >Priority: Blocker > > In ClassDumper.java example , We can not resolve symbol > {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not > have a JVM_CLASSFILE_MAGIC constant number. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (BCEL-299) Can not resolve symbol code
[ https://issues.apache.org/jira/browse/BCEL-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mingleizhang updated BCEL-299: -- Description: In ClassDumper.java , We can not resolve symbol {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not have a JVM_CLASSFILE_MAGIC constant number. > Can not resolve symbol code > --- > > Key: BCEL-299 > URL: https://issues.apache.org/jira/browse/BCEL-299 > Project: Commons BCEL > Issue Type: Bug >Reporter: mingleizhang >Priority: Blocker > > In ClassDumper.java , We can not resolve symbol > {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not > have a JVM_CLASSFILE_MAGIC constant number. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (BCEL-299) Can not resolve symbol code
[ https://issues.apache.org/jira/browse/BCEL-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mingleizhang updated BCEL-299: -- Description: In ClassDumper.java example , We can not resolve symbol {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not have a JVM_CLASSFILE_MAGIC constant number. (was: In ClassDumper.java , We can not resolve symbol {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not have a JVM_CLASSFILE_MAGIC constant number.) > Can not resolve symbol code > --- > > Key: BCEL-299 > URL: https://issues.apache.org/jira/browse/BCEL-299 > Project: Commons BCEL > Issue Type: Bug >Reporter: mingleizhang >Priority: Blocker > > In ClassDumper.java example , We can not resolve symbol > {{Constants.JVM_CLASSFILE_MAGIC}} in processID method as Constants does not > have a JVM_CLASSFILE_MAGIC constant number. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (BCEL-299) Can not resolve symbol code
mingleizhang created BCEL-299: - Summary: Can not resolve symbol code Key: BCEL-299 URL: https://issues.apache.org/jira/browse/BCEL-299 Project: Commons BCEL Issue Type: Bug Reporter: mingleizhang Priority: Blocker -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (BCEL-298) Add some files to .gitignore
[ https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mingleizhang updated BCEL-298: -- Priority: Minor (was: Critical) > Add some files to .gitignore > > > Key: BCEL-298 > URL: https://issues.apache.org/jira/browse/BCEL-298 > Project: Commons BCEL > Issue Type: Improvement >Reporter: mingleizhang >Priority: Minor > > We should not use git to track some files. Such as files with extension > suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (BCEL-297) Incorrect override implementation of Object.equals
[ https://issues.apache.org/jira/browse/BCEL-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238969#comment-16238969 ] ASF GitHub Bot commented on BCEL-297: - GitHub user zhangminglei opened a pull request: https://github.com/apache/commons-bcel/pull/20 [BCEL-297] Fix NPE in BCELComparator concrete implementations. This PR fix the potential NPE. You can merge this pull request into a Git repository by running: $ git pull https://github.com/zhangminglei/commons-bcel BCEL-297 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-bcel/pull/20.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 #20 commit 2338bf801caf437c3ee11cc666d2054c8f56d968 Author: zhangmingleiDate: 2017-11-04T12:43:35Z [BCEL-297] Fix NPE in BCELComparator concrete implementations. > Incorrect override implementation of Object.equals > -- > > Key: BCEL-297 > URL: https://issues.apache.org/jira/browse/BCEL-297 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts >Priority: Minor > > classfile/JavaClass.java: > classfile/Field.java: > classfile/Constant.java: > classfile/Method.java: > generic/FieldGen.java: > generic/MethodGen.java: > all define a bcelComparator that overrides Object.equals. However, they will > throw a null pointer exception for myConstant.equals(null) instead of > returning false. This non-standard behavior should either be corrected or > documented. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (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:all-tabpanel ] Michele Mariotti updated IO-554: Summary: FileUtils.copyToFile(InputStream source, File destination) closes input stream (was: copyToFile(InputStream source, File destination) closes input stream) > 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 >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] (IMAGING-198) Error while parsing JPEG with EXIF metadata with Imaging 1.0 (Sony DSC-R1)
[ https://issues.apache.org/jira/browse/IMAGING-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238960#comment-16238960 ] Bruno P. Kinoshita commented on IMAGING-198: Had some spare time today in a library nearby, and spent the day recapping the JPEG format (haven't looked at it since uni). Then spent some time in the evening debugging the code. So far I found `jhead -v 99f.jpg` a helpful command, showing the segments found, and displaying the metadata hierarchically. The image attached to this issue is a JPEG/EXIF image. It contains the APP1 marker, which is parsed with Commons Imaging TiffReader. This reader finds the initial directory, with 16 entries. All parsed successfully. Then the TiffReader reads another directory. And here's where I will have to continue investigating it later. This next directory starts with offset 0, and the ByteSource that it has reference is the initial ByteSource used for the first directory. This ByteSource has 764 bytes. But this second directory has 9128 bytes. And hence we have an exception in one of the if's that are used to prevent array out of bounds issues. Just need to re-read about the EXIF format, and its directories. See how TIFF differs in regards to EXIF, directories, ordering. Could be that TIFF expects this second directory, as after that some code is iterating subdirectories... > Error while parsing JPEG with EXIF metadata with Imaging 1.0 (Sony DSC-R1) > -- > > Key: IMAGING-198 > URL: https://issues.apache.org/jira/browse/IMAGING-198 > Project: Commons Imaging > Issue Type: Bug > Components: Format: JPEG >Affects Versions: 1.0 > Environment: Windows and Java 7u80 >Reporter: Samuel >Assignee: Bruno P. Kinoshita >Priority: Major > Labels: EXIF, JPEG > Attachments: 99f.jpg > > > An example of a JPEG image with EXIF metadata, coming from a Sony DSC-R1 > camera, that will not be parsed with commons-imaging 1.0. > http://imgur.com/a/fl9D9 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (BCEL-297) Incorrect override implementation of Object.equals
[ https://issues.apache.org/jira/browse/BCEL-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238958#comment-16238958 ] mingleizhang commented on BCEL-297: --- Hey, [~markro] We can just use {{Objects.equals}} to avoid this issue. Instead of throw a null pointer exception. but a false instead. I will give a PR to this issue. Thanks. > Incorrect override implementation of Object.equals > -- > > Key: BCEL-297 > URL: https://issues.apache.org/jira/browse/BCEL-297 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts >Priority: Minor > > classfile/JavaClass.java: > classfile/Field.java: > classfile/Constant.java: > classfile/Method.java: > generic/FieldGen.java: > generic/MethodGen.java: > all define a bcelComparator that overrides Object.equals. However, they will > throw a null pointer exception for myConstant.equals(null) instead of > returning false. This non-standard behavior should either be corrected or > documented. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (BCEL-298) Add some files to .gitignore
[ https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238954#comment-16238954 ] ASF GitHub Bot commented on BCEL-298: - GitHub user zhangminglei opened a pull request: https://github.com/apache/commons-bcel/pull/19 [BCEL-298] Add some files to .gitignore You can merge this pull request into a Git repository by running: $ git pull https://github.com/zhangminglei/commons-bcel BCEL-298 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-bcel/pull/19.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 #19 commit e88b2cc6c0b31ac6d260310947c778a39d9c36c3 Author: zhangmingleiDate: 2017-11-04T12:14:14Z [BCEL-298] Add some files to .gitignore > Add some files to .gitignore > > > Key: BCEL-298 > URL: https://issues.apache.org/jira/browse/BCEL-298 > Project: Commons BCEL > Issue Type: Improvement >Reporter: mingleizhang >Priority: Critical > > We should not use git to track some files. Such as files with extension > suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (BCEL-298) Add some files to .gitignore
[ https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238948#comment-16238948 ] mingleizhang edited comment on BCEL-298 at 11/4/17 12:04 PM: - Can anyone give me a permission that can contribute code to BCEL and assignee it to myself ? Thanks in advance. was (Author: mingleizhang): Can anyone give me a permission that can contributor code to BCEL and assignee it to myself ? Thanks in advance. > Add some files to .gitignore > > > Key: BCEL-298 > URL: https://issues.apache.org/jira/browse/BCEL-298 > Project: Commons BCEL > Issue Type: Improvement >Reporter: mingleizhang >Priority: Critical > > We should not use git to track some files. Such as files with extension > suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (BCEL-298) Add some files to .gitignore
[ https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238948#comment-16238948 ] mingleizhang commented on BCEL-298: --- Can anyone give me a permission that can contributor code to BCEL and assignee it to myself ? Thanks in advance. > Add some files to .gitignore > > > Key: BCEL-298 > URL: https://issues.apache.org/jira/browse/BCEL-298 > Project: Commons BCEL > Issue Type: Improvement >Reporter: mingleizhang >Priority: Critical > > We should not use git to track some files. Such as files with extension > suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (BCEL-298) Add some files to .gitignore
[ https://issues.apache.org/jira/browse/BCEL-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mingleizhang updated BCEL-298: -- Description: We should not use git to track some files. Such as files with extension suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. > Add some files to .gitignore > > > Key: BCEL-298 > URL: https://issues.apache.org/jira/browse/BCEL-298 > Project: Commons BCEL > Issue Type: Improvement >Reporter: mingleizhang >Priority: Critical > > We should not use git to track some files. Such as files with extension > suffix iml , suffix .idea if you are using Intellij IDEA as an IDE. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (BCEL-298) Add some files to .gitignore
mingleizhang created BCEL-298: - Summary: Add some files to .gitignore Key: BCEL-298 URL: https://issues.apache.org/jira/browse/BCEL-298 Project: Commons BCEL Issue Type: Improvement Reporter: mingleizhang Priority: Critical -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry
[ https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238930#comment-16238930 ] ASF GitHub Bot commented on TEXT-106: - Github user kinow commented on the issue: https://github.com/apache/commons-text/pull/73 Already done @ben12! Hope first pull request of many :-) > Exception thrown in ExtendedMessageFormat using quotes with custom registry > --- > > Key: TEXT-106 > URL: https://issues.apache.org/jira/browse/TEXT-106 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Benoît Moreau >Assignee: Bruno P. Kinoshita >Priority: Major > Attachments: ExtendedMessageFormat.java.patch, > ExtendedMessageFormatTest.java.patch > > > An exception is thrown when a quote is used just before end brace of format > element definition when a custom registry is used. > This exception is not thrown when a blank space is added before the end brace. > {code:java} > public static void main(String[] args) > { > String pattern = "TEST: {0,choice,0#0|0<'1'}"; > String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space > after quote > // Works fine > MessageFormat format0 = new MessageFormat(pattern); > System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern); > System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format2 = new > ExtendedMessageFormat(patternWorkaround, new HashMapFormatFactory>()); > System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 " > // Doesn't work > ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new > HashMap ()); > System.out.println(format3.format(new Integer[] { 0 })); // Exception > in thread "main" java.lang.IllegalArgumentException: Unterminated format > element at position 9 > System.out.println(format3.format(new Integer[] { 1 })); > } > {code} > Expected behavior: This exception should not be thrown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry
[ https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238928#comment-16238928 ] ASF GitHub Bot commented on TEXT-106: - Github user coveralls commented on the issue: https://github.com/apache/commons-text/pull/73 [![Coverage Status](https://coveralls.io/builds/14037929/badge)](https://coveralls.io/builds/14037929) Coverage increased (+0.1%) to 98.417% when pulling **3554c40a09288ba85313219c58e8084f3dcd885f on kinow:TEXT-106** into **e55d0ac1c17a7fd71dbb4f65034c7b739be6a35a on apache:master**. > Exception thrown in ExtendedMessageFormat using quotes with custom registry > --- > > Key: TEXT-106 > URL: https://issues.apache.org/jira/browse/TEXT-106 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Benoît Moreau >Assignee: Bruno P. Kinoshita >Priority: Major > Attachments: ExtendedMessageFormat.java.patch, > ExtendedMessageFormatTest.java.patch > > > An exception is thrown when a quote is used just before end brace of format > element definition when a custom registry is used. > This exception is not thrown when a blank space is added before the end brace. > {code:java} > public static void main(String[] args) > { > String pattern = "TEST: {0,choice,0#0|0<'1'}"; > String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space > after quote > // Works fine > MessageFormat format0 = new MessageFormat(pattern); > System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern); > System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format2 = new > ExtendedMessageFormat(patternWorkaround, new HashMapFormatFactory>()); > System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 " > // Doesn't work > ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new > HashMap ()); > System.out.println(format3.format(new Integer[] { 0 })); // Exception > in thread "main" java.lang.IllegalArgumentException: Unterminated format > element at position 9 > System.out.println(format3.format(new Integer[] { 1 })); > } > {code} > Expected behavior: This exception should not be thrown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry
[ https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238929#comment-16238929 ] ASF GitHub Bot commented on TEXT-106: - Github user coveralls commented on the issue: https://github.com/apache/commons-text/pull/73 [![Coverage Status](https://coveralls.io/builds/14037929/badge)](https://coveralls.io/builds/14037929) Coverage increased (+0.1%) to 98.417% when pulling **3554c40a09288ba85313219c58e8084f3dcd885f on kinow:TEXT-106** into **e55d0ac1c17a7fd71dbb4f65034c7b739be6a35a on apache:master**. > Exception thrown in ExtendedMessageFormat using quotes with custom registry > --- > > Key: TEXT-106 > URL: https://issues.apache.org/jira/browse/TEXT-106 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Benoît Moreau >Assignee: Bruno P. Kinoshita >Priority: Major > Attachments: ExtendedMessageFormat.java.patch, > ExtendedMessageFormatTest.java.patch > > > An exception is thrown when a quote is used just before end brace of format > element definition when a custom registry is used. > This exception is not thrown when a blank space is added before the end brace. > {code:java} > public static void main(String[] args) > { > String pattern = "TEST: {0,choice,0#0|0<'1'}"; > String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space > after quote > // Works fine > MessageFormat format0 = new MessageFormat(pattern); > System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern); > System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format2 = new > ExtendedMessageFormat(patternWorkaround, new HashMapFormatFactory>()); > System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 " > // Doesn't work > ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new > HashMap ()); > System.out.println(format3.format(new Integer[] { 0 })); // Exception > in thread "main" java.lang.IllegalArgumentException: Unterminated format > element at position 9 > System.out.println(format3.format(new Integer[] { 1 })); > } > {code} > Expected behavior: This exception should not be thrown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry
[ https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238924#comment-16238924 ] ASF GitHub Bot commented on TEXT-106: - Github user ben12 commented on the issue: https://github.com/apache/commons-text/pull/73 I have corrected my patch https://github.com/kinow/commons-text/pull/1 It is my first pull request, so if I have understand the worlflow, kinow must accept it to re-pull it here. > Exception thrown in ExtendedMessageFormat using quotes with custom registry > --- > > Key: TEXT-106 > URL: https://issues.apache.org/jira/browse/TEXT-106 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Benoît Moreau >Assignee: Bruno P. Kinoshita >Priority: Major > Attachments: ExtendedMessageFormat.java.patch, > ExtendedMessageFormatTest.java.patch > > > An exception is thrown when a quote is used just before end brace of format > element definition when a custom registry is used. > This exception is not thrown when a blank space is added before the end brace. > {code:java} > public static void main(String[] args) > { > String pattern = "TEST: {0,choice,0#0|0<'1'}"; > String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space > after quote > // Works fine > MessageFormat format0 = new MessageFormat(pattern); > System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern); > System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format2 = new > ExtendedMessageFormat(patternWorkaround, new HashMapFormatFactory>()); > System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 " > // Doesn't work > ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new > HashMap ()); > System.out.println(format3.format(new Integer[] { 0 })); // Exception > in thread "main" java.lang.IllegalArgumentException: Unterminated format > element at position 9 > System.out.println(format3.format(new Integer[] { 1 })); > } > {code} > Expected behavior: This exception should not be thrown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IO-554) copyToFile(InputStream source, File destination) closes input stream
Michele Mariotti created IO-554: --- Summary: 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 Priority: Blocker 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] (TEXT-106) Exception thrown in ExtendedMessageFormat using quotes with custom registry
[ https://issues.apache.org/jira/browse/TEXT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238905#comment-16238905 ] ASF GitHub Bot commented on TEXT-106: - Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-text/pull/73 patch has some check-style violations, see: https://travis-ci.org/apache/commons-text/jobs/294087452 > Exception thrown in ExtendedMessageFormat using quotes with custom registry > --- > > Key: TEXT-106 > URL: https://issues.apache.org/jira/browse/TEXT-106 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Benoît Moreau >Assignee: Bruno P. Kinoshita >Priority: Major > Attachments: ExtendedMessageFormat.java.patch, > ExtendedMessageFormatTest.java.patch > > > An exception is thrown when a quote is used just before end brace of format > element definition when a custom registry is used. > This exception is not thrown when a blank space is added before the end brace. > {code:java} > public static void main(String[] args) > { > String pattern = "TEST: {0,choice,0#0|0<'1'}"; > String patternWorkaround = "TEST: {0,choice,0#0|0<'1' }"; // a space > after quote > // Works fine > MessageFormat format0 = new MessageFormat(pattern); > System.out.println(format0.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format0.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format1 = new ExtendedMessageFormat(pattern); > System.out.println(format1.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format1.format(new Integer[] { 1 })); // "TEST: 1" > // Works fine > ExtendedMessageFormat format2 = new > ExtendedMessageFormat(patternWorkaround, new HashMapFormatFactory>()); > System.out.println(format2.format(new Integer[] { 0 })); // "TEST: 0" > System.out.println(format2.format(new Integer[] { 1 })); // "TEST: 1 " > // Doesn't work > ExtendedMessageFormat format3 = new ExtendedMessageFormat(pattern, new > HashMap ()); > System.out.println(format3.format(new Integer[] { 0 })); // Exception > in thread "main" java.lang.IllegalArgumentException: Unterminated format > element at position 9 > System.out.println(format3.format(new Integer[] { 1 })); > } > {code} > Expected behavior: This exception should not be thrown. -- This message was sent by Atlassian JIRA (v6.4.14#64029)