[jira] [Closed] (CODEC-138) Complete FilterInputStream interface for BaseNCodecInputStream
[ https://issues.apache.org/jira/browse/CODEC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed CODEC-138. - In SVN. > Complete FilterInputStream interface for BaseNCodecInputStream > -- > > Key: CODEC-138 > URL: https://issues.apache.org/jira/browse/CODEC-138 > Project: Commons Codec > Issue Type: Improvement >Reporter: Thomas Neidhart > Fix For: 1.7 > > Attachments: CODEC-138.patch > > > Small patch to implement mark and reset in a safe manner. > markSupported is already implemented, but the other two methods are inherited > from the default FilterInputStream implementation, which calls the > corresponding methods of the underlying stream. The patch provides a noop > implementation for mark, and throws an IOException when reset is called. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-275) org.apache.commons.io.FileUtils.contentEquals - Add option to ignore "line endings"
[ https://issues.apache.org/jira/browse/IO-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-275. -- Version 2.2 has been released and addresses this issue. > org.apache.commons.io.FileUtils.contentEquals - Add option to ignore "line > endings" > --- > > Key: IO-275 > URL: https://issues.apache.org/jira/browse/IO-275 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Reporter: CJ Aspromgos > Fix For: 2.2 > > > FileUtils has a nice member function to compare two files. It would be nice > if the client had the option to ignore line endings. This way files > (specifically text files) generated on different platforms (eg windows, unix) > would match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-290) Add read/readFully methods to IOUtils
[
https://issues.apache.org/jira/browse/IO-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-290.
--
Version 2.2 has been released and addresses this issue.
> Add read/readFully methods to IOUtils
> -
>
> Key: IO-290
> URL: https://issues.apache.org/jira/browse/IO-290
> Project: Commons IO
> Issue Type: New Feature
>Reporter: Sebb
> Fix For: 2.2
>
>
> When reading from network etc, it's possible for a read to return before it
> has read as many bytes as would fit in the buffer.
> Sometimes multiple reads are needed to fulfil the request.
> It would be useful to have read() versions of the skip() methods.
> {code}
> int actual = read(Reader, byte buffer [,offset, length]) // returns normally
> on EOF
> int actual = read(InputStream, char buffer [,offset, length])
> int actual = readFully(Reader, byte buffer [,offset, length]) // throws
> EOFException
> int actual = readFully(InputStream, char buffer [,offset, length])
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-288) Supply a ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/IO-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-288.
--
Version 2.2 has been released and addresses this issue.
> Supply a ReversedLinesFileReader
> -
>
> Key: IO-288
> URL: https://issues.apache.org/jira/browse/IO-288
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Georg Henzler
> Fix For: 2.2
>
> Attachments: ReversedLinesFileReader0.3.zip
>
>
> I needed to analyse a log file today and I was looking for a
> ReversedLinesFileReader: A class that behaves exactly like BufferedReader
> except that it goes from bottom to top when readLine() is called. I didn't
> find it in IOUtils and the internet didn't help a lot either, e.g.
> http://www.java2s.com/Tutorial/Java/0180__File/ReversingaFile.htm is a fairly
> inefficient - the log files I'm analysing are huge and it is not a good idea
> to load the whole content in the memory.
> So I ended up writing an implementation myself using little memory and the
> class RandomAccessFile - see attached file. It's used as follows:
> int blockSize = 4096; // only that much memory is needed, no matter how big
> the file is
> ReversedLinesFileReader reversedLinesFileReader = new ReversedLinesFileReader
> (myFile, blockSize, "UTF-8"); // encoding is supported
> String line = null;
> while((line=reversedLinesFileReader.readLine())!=null) {
> ... // use the line
> if(enoughLinesSeen) {
> break;
> }
> }
> reversedLinesFileReader.close();
> I believe this could be useful for other people as well!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-291) Add new function FileUtils.directoryContains
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-291. -- Resolution: Fixed Version 2.2 has been released and addresses this issue. > Add new function FileUtils.directoryContains > > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Attachments: io-291-simple.diff, io-291-v5.patch > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-292) IOUtils.closeQuietly() should take a ServerSocket as a parameter
[ https://issues.apache.org/jira/browse/IO-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-292. -- Version 2.2 has been released and addresses this issue. > IOUtils.closeQuietly() should take a ServerSocket as a parameter > > > Key: IO-292 > URL: https://issues.apache.org/jira/browse/IO-292 > Project: Commons IO > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > Fix For: 2.2 > > > Unfortunately ServerSocket does not implement Closeable, nor does it extend > Socket, so none of the existing closeQuietly() methods can be used. > Might be useful to implement this as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-301) Add IOUtils.closeQuietly(Selector)
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-301. -- Version 2.2 has been released and addresses this issue. > Add IOUtils.closeQuietly(Selector) > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-298) Various methods of class 'org.apache.commons.io.FileUtils' incorrectly suppress 'java.io.IOException's.
[ https://issues.apache.org/jira/browse/IO-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-298. -- Version 2.2 has been released and addresses this issue. > Various methods of class 'org.apache.commons.io.FileUtils' incorrectly > suppress 'java.io.IOException's. > --- > > Key: IO-298 > URL: https://issues.apache.org/jira/browse/IO-298 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.1 >Reporter: Christian Schulte >Priority: Critical > Labels: patch > Fix For: 2.2 > > Attachments: IO-298.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-302) ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without BOM multiple times
[ https://issues.apache.org/jira/browse/IO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-302. -- Version 2.2 has been released and addresses this issue. > ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without > BOM multiple times > --- > > Key: IO-302 > URL: https://issues.apache.org/jira/browse/IO-302 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.1 > Environment: Win7 64bit, Java 6 32bit >Reporter: Jan Steuerwald >Assignee: Gary D. Gregory > Fix For: 2.2 > > Attachments: IO-302.patch, Test.java, testfileBOM.xml, > testfileNoBOM.xml > > > Resetting the BOMInputStream doesn't reset the _fbLength_ member variable. > This causes _fbLength_ to grow bigger than the _firstBytes_ array (when the > file doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException > in the _readFirstBytes_ method. > The attached test case reveals the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-296) ReaderInputStream optimization: more efficient reading of small chunks of data
[ https://issues.apache.org/jira/browse/IO-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-296. -- Version 2.2 has been released and addresses this issue. > ReaderInputStream optimization: more efficient reading of small chunks of data > -- > > Key: IO-296 > URL: https://issues.apache.org/jira/browse/IO-296 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Oleg Kalnichevski > Fix For: 2.2 > > Attachments: commons-io-readerinputstream-optimization.patch > > > ReaderInputStream in its current form does not efficiently handle reading of > small data chunks. #read(byte[] b, int off, int len) methods compacts > encoderOut on every read operation, which is not very efficient if the chunks > of data being read are smallish. This especially affects the #read() method, > which currently reads one byte of data into a temporary byte array. Not to > mention that allocation of a temporary byte array on each #read() method > invocation leads to generation of unnecessary intermediate garbage on the > heap. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-273) BoundedInputStream.read() treats max differently from BoundedInputStream.read(byte[]...)
[ https://issues.apache.org/jira/browse/IO-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-273. -- Version 2.2 has been released and addresses this issue. > BoundedInputStream.read() treats max differently from > BoundedInputStream.read(byte[]...) > > > Key: IO-273 > URL: https://issues.apache.org/jira/browse/IO-273 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Reporter: Sebb >Priority: Minor > Fix For: 2.2 > > > BoundedInputStream.read() treats max differently from > BoundedInputStream.read(byte[]...) > read() checks for pos == max, whereas read(byte[]...) checks for pos >= max. > The latter check is safer (works even if pos overshoots max). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-173) FileUtils.listFiles() doesn't return directories
[
https://issues.apache.org/jira/browse/IO-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-173.
--
Version 2.2 has been released and addresses this issue.
> FileUtils.listFiles() doesn't return directories
>
>
> Key: IO-173
> URL: https://issues.apache.org/jira/browse/IO-173
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.4
>Reporter: François Loison
> Fix For: 2.2
>
> Attachments: IO-173.patch, IO-173.patch
>
>
> FileUtils.listFiles() returns only files and not directories.
> So it can't be used to retrieve sub-directories.
> Some fix could be applied:
> {code}
> private static void innerListFiles(Collection files, File directory,
> IOFileFilter filter) {
> File[] found = directory.listFiles((FileFilter) filter);
> if (found != null) {
> for (int i = 0; i < found.length; i++) {
> if (found[i].isDirectory()) {
> >>> fix
> if ( addDirectories ) {
>files.add(found[i]);
> }
> >>> end fix
> innerListFiles(files, found[i], filter);
> } else {
> files.add(found[i]);
> }
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-276) "FileUtils#deleteDirectoryOnExit(File)" does not work
[
https://issues.apache.org/jira/browse/IO-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-276.
--
Version 2.2 has been released and addresses this issue.
> "FileUtils#deleteDirectoryOnExit(File)" does not work
> -
>
> Key: IO-276
> URL: https://issues.apache.org/jira/browse/IO-276
> Project: Commons IO
> Issue Type: Bug
> Environment: Commons IO 1.4
>Reporter: nkami
>Priority: Minor
> Fix For: 2.2
>
> Attachments: IO-276-r1201108-patch.txt
>
>
> I called this method, but the target directory was not deleted.
> The source of this method is as follows.
> --
> private static void deleteDirectoryOnExit(File directory) throws
> IOException {
> if (!directory.exists()) {
> return;
> }
> cleanDirectoryOnExit(directory);
> directory.deleteOnExit();
> }
> --
> In other words, this method calls "java.io.File#deleteOnExit" in order of
> "grandchildren -> children -> parent" for files of the target directory
> hierarchy.
> There is following mention in javadoc of "java.io.File#deleteOnExit".
> --
> Files (or directories) are deleted in the reverse order that they are
> registered.
> --
> Therefore, I think the calling order of "java.io.File#deleteOnExit" should be
> reverse.
> How will be it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-297) CharSequenceInputStream to efficiently stream content of a CharSequence
[ https://issues.apache.org/jira/browse/IO-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-297. -- Version 2.2 has been released and addresses this issue. > CharSequenceInputStream to efficiently stream content of a CharSequence > --- > > Key: IO-297 > URL: https://issues.apache.org/jira/browse/IO-297 > Project: Commons IO > Issue Type: Improvement >Reporter: Oleg Kalnichevski > Fix For: 2.2 > > Attachments: commons-io-charseqinputstream.patch > > > CharSequenceInputStream implementation can be used to efficiently stream > content of a CharSequence. This can be useful when streaming out a large body > of text to a network socket without having to create an intermediate byte > array containing the entire content in binary form (using > String#toByteArray() or similar). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-307) ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters
[ https://issues.apache.org/jira/browse/IO-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-307. -- Version 2.2 has been released and addresses this issue. > ReaderInputStream#read(byte[] b, int off, int len) should check for valid > parameters > > > Key: IO-307 > URL: https://issues.apache.org/jira/browse/IO-307 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sebb > Fix For: 2.2 > > > If the buffer is null, the method should throw NPE immediately (rather than > letting it occur later) > If the offset or length are < 0 or would overflow the buffer, then throw > IndexOutOfBoundsException with details of the values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-306) ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0
[ https://issues.apache.org/jira/browse/IO-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-306. -- Version 2.2 has been released and addresses this issue. > ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for > length == 0 > - > > Key: IO-306 > URL: https://issues.apache.org/jira/browse/IO-306 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sebb > Fix For: 2.2 > > > The method read(byte[] b, int off, int len) should always return 0 if the > requested length == 0, even if the stream is empty or at EOF, as that is how > the overridden java.io.InputStream method is documented to behave. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-300) FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory
[
https://issues.apache.org/jira/browse/IO-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-300.
--
Version 2.2 has been released and addresses this issue.
> FileUtils.moveDirectoryToDirectory removes source directory if destination is
> a subdirectory
>
>
> Key: IO-300
> URL: https://issues.apache.org/jira/browse/IO-300
> Project: Commons IO
> Issue Type: Bug
>Reporter: dennis lucero
> Fix For: 2.2
>
> Attachments: IO-300.patch
>
>
> Since moveDirectoryToDirectory performs a copy then delete, if you specify a
> target directory that is a subdirectory of the source, everything under the
> source directory is deleted.
> Steps to recreate:
> File dest = new File("/tmp/dir1/dir2");
> File src = new File("/tmp/dir1/");
> dest.mkdirs();
> System.out.println(src.exists());
> FileUtils.moveDirectoryToDirectory(src, dest, false);
> System.out.println(src.exists());
> Output:
> true
> false
> If you try the same thing with a move command on Linux, you receive: "mv:
> cannot move `dir1/' to a subdirectory of itself, `dir1/dir2/dir1'"
> Maybe throw an exception if
> dest.getCanonicalPath().startsWith(src.getCanonicalPath())
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-312) CharSequenceInputStream(CharSequence s, Charset charset, int bufferSize) ignores bufferSize
[ https://issues.apache.org/jira/browse/IO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-312. -- Version 2.2 has been released and addresses this issue. > CharSequenceInputStream(CharSequence s, Charset charset, int bufferSize) > ignores bufferSize > --- > > Key: IO-312 > URL: https://issues.apache.org/jira/browse/IO-312 > Project: Commons IO > Issue Type: Bug >Reporter: Sebb > Fix For: 2.2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-305) New copy() method in IOUtils that takes additional offset, length and buffersize arguments
[ https://issues.apache.org/jira/browse/IO-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-305. -- Version 2.2 has been released and addresses this issue. > New copy() method in IOUtils that takes additional offset, length and > buffersize arguments > -- > > Key: IO-305 > URL: https://issues.apache.org/jira/browse/IO-305 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Reporter: Manoj Mokashi >Priority: Minor > Fix For: 2.2 > > Attachments: IOUtils.java, IOUtilsTest.java > > > /** > * Copy from input to output stream > * @param is : input stream > * @param os : output stream > * @param offset : number of bytes to skip from input before copying > * -ve values are ignored > * @param len : number of bytes to copy. -1 means all > * @param bufferSize : buffer size to use for copying > * @throws IOException > */ > public static void copy( InputStream is, OutputStream os, int offset, int > len, int bufferSize) throws IOException > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-311) IOUtils.read(InputStream/Reader) ignores the offset parameter
[ https://issues.apache.org/jira/browse/IO-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-311. -- Version 2.2 has been released and addresses this issue. > IOUtils.read(InputStream/Reader) ignores the offset parameter > - > > Key: IO-311 > URL: https://issues.apache.org/jira/browse/IO-311 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Reporter: Robert Muir > Fix For: 2.2 > > Attachments: IO-311.patch > > > IOUtils.read(InputStream input, byte[] buffer, int offset, int length) and > read(Reader input, char[] buffer, int offset, int length) don't take the > offset parameter into account... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-313) Add IOUTils.toBufferedReader(Reader)
[ https://issues.apache.org/jira/browse/IO-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-313. -- Version 2.2 has been released and addresses this issue. > Add IOUTils.toBufferedReader(Reader) > > > Key: IO-313 > URL: https://issues.apache.org/jira/browse/IO-313 > Project: Commons IO > Issue Type: New Feature >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 2.2 > > > Add IOUTils.toBufferedReader(Reader) to return a new BufferedReader unless > the given Reader is already a BufferedReader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-308) Allow applications to provide buffer (or size) for copyLarge methods?
[ https://issues.apache.org/jira/browse/IO-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-308. -- Version 2.2 has been released and addresses this issue. > Allow applications to provide buffer (or size) for copyLarge methods? > - > > Key: IO-308 > URL: https://issues.apache.org/jira/browse/IO-308 > Project: Commons IO > Issue Type: New Feature >Reporter: Sebb >Priority: Minor > Fix For: 2.2 > > > Unlike the skip buffer, the copyLarge buffers cannot be shared between > threads. > The methods allocate their own buffers as local variables (current size 4096) > It might be worth allowing applications to provide their own buffers, and/or > specifying the buffer size to be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COMMONSSITE-66) Add support for a "commons.release.3" set of properties to offer a 3rd download option
[ https://issues.apache.org/jira/browse/COMMONSSITE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed COMMONSSITE-66. -- Closing. About to cut RC. As closed this will show up in the site JIRA report. > Add support for a "commons.release.3" set of properties to offer a 3rd > download option > -- > > Key: COMMONSSITE-66 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-66 > Project: Commons All > Issue Type: New Feature > Components: Commons Build Plugin > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_31, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_31\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > > Add support for a "commons.release.3" set of properties to offer a 3rd > download option: commons.release.3.* will be just like commons.release.2.* -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (POOL-208) Support Java 1.5 Generics in version 1.x.
[ https://issues.apache.org/jira/browse/POOL-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed POOL-208. Released as 1.6. > Support Java 1.5 Generics in version 1.x. > - > > Key: POOL-208 > URL: https://issues.apache.org/jira/browse/POOL-208 > Project: Commons Pool > Issue Type: Improvement > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 1.6 > > > Support Java 1.5 Generics in version 1.x. > Create a 1.x release with generics. Right now, that would be 1.6. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed CODEC-125. - Resolution: Fixed Assignee: Gary D. Gregory Released in 1.6. > Implement a Beider-Morse phonetic matching codec > > > Key: CODEC-125 > URL: https://issues.apache.org/jira/browse/CODEC-125 > Project: Commons Codec > Issue Type: New Feature >Reporter: Matthew Pocock >Assignee: Gary D. Gregory >Priority: Minor > Fix For: 1.6 > > Attachments: Rule$4$1-All_Objects.html, acz.patch, bm-gg.diff, > bm-set-broken.diff, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, > bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, comparator.patch, > fightingMemoryChurn.patch, fightingMemoryChurn.patch, fixmeInvariant.patch, > handleH.patch, majorFix.patch, performanceAndBugs.patch, > testAllChars-mem-profile.html, testEncodeGna.patch > > > I have implemented Beider Morse Phonetic Matching as a codec against the > commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (POOL-191) ConcurrentModificationException in GenericObjectPool LinkedList
[
https://issues.apache.org/jira/browse/POOL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed POOL-191.
Resolution: Not A Problem
> ConcurrentModificationException in GenericObjectPool LinkedList
> ---
>
> Key: POOL-191
> URL: https://issues.apache.org/jira/browse/POOL-191
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 1.5.6
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>
> It is possible to get a {{ConcurrentModificationException}} in a
> {{LinkedList}} from a {{GenericObjectPool}}.
> This happens when I call {{ReflectionToStringBuilder.toString(this)}} from a
> subclass of {{GenericObjectPool}}. My guess is that it would happen with just
> {{ReflectionToStringBuilder.toString(gop)}}. IOW, subclassing does not have
> anything to do with it I would venture.
> For example, in this stack trace {{JmsSessionPool}} is a subclass of
> {{GenericObjectPool}}.
> {noformat}
> java.util.ConcurrentModificationException
> at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
> at java.util.LinkedList$ListItr.next(LinkedList.java:696)
> at java.util.AbstractCollection.toString(AbstractCollection.java:421)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuffer.append(StringBuffer.java:219)
> at
> org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598)
> at
> org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473)
> at
> org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
> at
> org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119)
> at
> com.seagullsw.appinterface.comm.jms.JmsSessionPool.toString(JmsSessionPool.java:120)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuffer.append(StringBuffer.java:219)
> at
> org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:586)
> at
> org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:550)
> at
> org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
> at
> org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:689)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119)
> at
> com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:828)
> at
> com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:817)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at
> com.seagullsw.appinterface.server.AisHelper.waitForCommuncationManagers(AisHelper.java:217)
> at com.seagullsw.appinterface.server.AisHelper.start(AisHelper.java:136)
> at
> com.seagullsw.appinterface.server.AisHelper.startFromResource(AisHelper.java:161)
> at
> com.seagullsw.appinterface.server.AbstractServerJunit4.startServer(AbstractServerJunit4.java:179)
> at
> com.seagullsw.appinterface.server.comm.jms.AbstractJmsRoundtripMaxConcurrencyTestCase.setUpOnce(AbstractJmsRoundtripMaxConcurrencyTestCase.java:141)
> at
> com.seagullsw.appinterface.server.comm.jms.ibmmq.JmsRoundtripMaxConcurrency032TestCase.setUpOnce(JmsRoundtripMaxConcurrency032TestCase.java:40)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-266) FileUtils.copyFile() throws IOException when copying large files to a shared directory (on Windows)
[
https://issues.apache.org/jira/browse/IO-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-266.
--
Closing, we released version 2.1.
> FileUtils.copyFile() throws IOException when copying large files to a shared
> directory (on Windows)
> ---
>
> Key: IO-266
> URL: https://issues.apache.org/jira/browse/IO-266
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Windows 2003 Server 64-bit
>Reporter: Igor Smereka
> Fix For: 2.1
>
> Attachments: FileUtils.java.patch
>
>
> java.io.IOException: Insufficient system resources exist to complete the
> requested service
> at sun.nio.ch.FileDispatcher.pwrite0(Native Method)
> at sun.nio.ch.FileDispatcher.pwrite(Unknown Source)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(Unknown Source)
> at sun.nio.ch.IOUtil.write(Unknown Source)
> at sun.nio.ch.FileChannelImpl.write(Unknown Source)
> at sun.nio.ch.FileChannelImpl.transferFromFileChannel(Unknown Source)
> at sun.nio.ch.FileChannelImpl.transferFrom(Unknown Source)
> at org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:813)
> at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:783)
> at org.test.igor.TestFileUtils.main(TestFileUtils.java:55)
> NOTE: the issue is cased by the function doCopyFile(File srcFile, File
> destFile, boolean preserveFileDate) using hardcoded data chunks of FIFTY_MB
> in the transferFrom() call.
> Reducing this chunk from 50M to 31M solves the issue for my situation (32M
> still fails).
> Here is a test program to reproduce the issue:
> package org.test.igor;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.nio.channels.FileChannel;
> import org.apache.commons.io.FileUtils;
> import org.apache.commons.io.IOUtils;
> public class TestFileUtils {
> public static void main(String[] args){
>
>
> File src = new File("D:\\2011.1-dev\\test\\test");
> File dest = new File("ismerek1\\Shared");
>
> String filename = "jdk-6u19-windows-x64.exe";
>
> File file = new File(src, filename);
> File toFile = new File(dest, filename);
>
> try {
> FileUtils.copyFile(file, toFile, true);
> System.out.println("Successful copy");
> }
> catch (IOException e1) {
> e1.printStackTrace();
> }
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-274) Tailer returning partial lines when reaching EOF before EOL
[ https://issues.apache.org/jira/browse/IO-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-274. -- Closing, we released version 2.1. > Tailer returning partial lines when reaching EOF before EOL > --- > > Key: IO-274 > URL: https://issues.apache.org/jira/browse/IO-274 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Frank Grimes > Fix For: 2.1 > > Attachments: TailerTest.patch > > > As reported here: > http://mail-archives.apache.org/mod_mbox/commons-user/201105.mbox/%3cbanlktim6ha-xgjn8ca6ffcpkva6ax6k...@mail.gmail.com%3e -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-263) FileSystemUtils.freeSpaceKb throws exception for Windows volumes with no visible files.
[
https://issues.apache.org/jira/browse/IO-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-263.
--
Closing, we released version 2.1.
> FileSystemUtils.freeSpaceKb throws exception for Windows volumes with no
> visible files.
> ---
>
> Key: IO-263
> URL: https://issues.apache.org/jira/browse/IO-263
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.0.1
> Environment: Windows XP SP3
>Reporter: Gil Adam
> Fix For: 2.1
>
>
> Doing a FileSystemUtils.freeSpaceKb("D:/") where the drive (in this example
> d:\) is an empty drive (A drive with no non-hidden files on it yet) results
> in an exception being thrown.
> "Command line returned OS error code '1' for command [cmd.exe, /C, dir
> /-c "D:\"]
> Perhaps it could do a "dir /a /-c" to work in more cases? (Since hidden file
> "System Volume Information" will usually be available)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-251) Add new read method "toByteArray" to handle InputStream with known size
[ https://issues.apache.org/jira/browse/IO-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-251. -- Closing, we released version 2.1. > Add new read method "toByteArray" to handle InputStream with known size > --- > > Key: IO-251 > URL: https://issues.apache.org/jira/browse/IO-251 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.4 >Reporter: Marco Albini >Priority: Minor > Fix For: 2.1 > > Attachments: IO-251_toByteArray.patch > > > I suggest adding a new method toByteArray(InputStream input, int size) to > IoUtils to handle known size InputStream (e.g. files). > Current implementation based on copy method consumes more memory than > necessary (at least the double) to transform a InputStream into a byte array. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)
[ https://issues.apache.org/jira/browse/IO-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-259. -- Closing, we released version 2.1. > FileAlterationMonitor.stop(boolean allowIntervalToFinish) > - > > Key: IO-259 > URL: https://issues.apache.org/jira/browse/IO-259 > Project: Commons IO > Issue Type: Improvement >Reporter: Dan Checkoway >Assignee: Niall Pemberton > Fix For: 2.1 > > Attachments: IO-259.patch > > > I'm a long-time user of commons-io, but I just started using > FileAlterationMonitor the other day. I have a bean in a Spring application > context that constructs a FileAlterationMonitor, and it sets the > ThreadFactory to an instance that creates daemon threads. At context > shutdown, my bean calls .stop() on the monitor. > The problem is that .stop() currently honors the Thread.sleep(interval), in > that it does a nice friendly thread.join(). If you set your interval high > enough, your "graceful app shutdown" is going to sit there waiting a while. > Compounding things is that I have *seven* FileAlterationMonitors in my app, > all of which run with a 10-second sleep time. So at graceful shutdown time, > I'm facing a delay of up to 70 seconds...lame! > So I stopped calling .stop() and since the ThreadFactory created daemon > threads, shutdown is quick. But... > I'm running inside tomcat, and when it shuts down it looks for leaks. And of > course it finds a handful of my threads and complains, such as: > SEVERE: The web application [/my-webapp] appears to have started a thread > named [FileUpdateMonitor-/path/to/my/file.ext] but has failed to stop it. > This is very likely to create a memory leak. > So what I'm suggesting is an alternate version of > FileAlterationMonitor.stop() that takes "boolean allowIntervalToFinish". The > default behavior won't change (for backward compatibility). But if you > explicitly call .stop(false), then it will interrupt the sleeping thread > immediately. That thread wakes up, sees that running=false, and finishes up > immediately. > Patch will be attached in a sec... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-260) ClassLoaderObjectInputStream does not handle Proxy classes
[ https://issues.apache.org/jira/browse/IO-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-260. -- Closing, we released version 2.1. > ClassLoaderObjectInputStream does not handle Proxy classes > -- > > Key: IO-260 > URL: https://issues.apache.org/jira/browse/IO-260 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.0.1 >Reporter: John Carrino >Assignee: Niall Pemberton > Fix For: 2.1 > > > ObjectInputSteam has 2 methods that need to be overloaded for proper behavior > in this case. > resolveClass is ok, but resolveProxyClass doesn't attempt to look in the > passed class loader to resolve the interfaces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-182) Add new APPEND parameter for writing string into files
[ https://issues.apache.org/jira/browse/IO-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-182. -- Closing, we released version 2.1. > Add new APPEND parameter for writing string into files > -- > > Key: IO-182 > URL: https://issues.apache.org/jira/browse/IO-182 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 1.4 >Reporter: Stefan Simik >Assignee: Niall Pemberton > Fix For: 2.1 > > Attachments: patch-add-append-to-write-fonctions.patch > > > It would be great to have one additional parameter for writing strins into > file - boolean append. > If true, string will be appended to the end of the file. > It is very useful for many purposes, for example logging and so on.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-264) FileUtils.moveFile() JavaDoc should specify FileExistsException thrown
[ https://issues.apache.org/jira/browse/IO-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-264. -- Closing, we released version 2.1. > FileUtils.moveFile() JavaDoc should specify FileExistsException thrown > -- > > Key: IO-264 > URL: https://issues.apache.org/jira/browse/IO-264 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.0 >Reporter: Maciej Biłas >Assignee: Niall Pemberton >Priority: Trivial > Fix For: 2.1 > > > FileUtils.moveFile() JavaDoc does specify the behaviour of the method in a > case when the destFile exists. It would be helpful to know from the JavaDoc > that in such case an exception is thrown as it's not immediately obvious. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-280) Dubious use of mkdirs() return code
[
https://issues.apache.org/jira/browse/IO-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-280.
--
Closing, we released version 2.1.
> Dubious use of mkdirs() return code
> ---
>
> Key: IO-280
> URL: https://issues.apache.org/jira/browse/IO-280
> Project: Commons IO
> Issue Type: Bug
>Reporter: Sebb
>Priority: Minor
>
> FileUtils.openOutputStream() has the following code:
> {code}
> File parent = file.getParentFile();
> if (parent != null && parent.exists() == false) {
> if (parent.mkdirs() == false) {
> throw new IOException("File '" + file + "' could not be created");
> }
> }
> {code}
> Now mkdirs() returns true only if the method actually created the
> directories; it's theoretically possible for the directory to be created in
> the window between the exists() and mkdirs() invocations. [Indeed the class
> actually checks for this in the forceMkdir() method]
> It would be safer to use:
> {code}
> File parent = file.getParentFile();
> if (parent != null && !parent.mkdirs() && !parent.isDirectory()) {
> throw new IOException("Directory '" + parent + "' could not be
> created"); // note changed text
> }
> }
> {code}
> Similarly elsewhere in the class where mkdirs() is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-261) Add FileUtils.getFile API with varargs parameter
[
https://issues.apache.org/jira/browse/IO-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-261.
--
Closing, we released version 2.1.
> Add FileUtils.getFile API with varargs parameter
>
>
> Key: IO-261
> URL: https://issues.apache.org/jira/browse/IO-261
> Project: Commons IO
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Assignee: Niall Pemberton
>Priority: Minor
> Labels: features
> Fix For: 2.1
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Why not have those in FileUtils?
> public static File getFile(final String... dirs) {
> File ret = null;
> for (String dir : dirs) {
> if (ret == null) {
> ret = new File(dir);
> } else {
> ret = new File(ret.getPath(), dir);
> }
> }
> return ret;
> }
> public static File getFile(final File dir, final String... dirs) {
> File ret = dir;
> for (String dir1 : dirs) {
> if (ret == null) {
> ret = new File(dir1);
> } else {
> ret = new File(ret.getPath(), dir1);
> }
> }
> return ret;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-277) ReaderInputStream enters infinite loop when it encounters an unmappable character
[
https://issues.apache.org/jira/browse/IO-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-277.
--
Closing, we released version 2.1.
> ReaderInputStream enters infinite loop when it encounters an unmappable
> character
> -
>
> Key: IO-277
> URL: https://issues.apache.org/jira/browse/IO-277
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.0.1
>Reporter: Mike Thomas
>Assignee: Niall Pemberton
> Fix For: 2.1
>
> Attachments: TestReaderInputStreamLoop.java
>
>
> The ReaderInputStream.read(byte[] b, int off, int len) method enters an
> infinite loop when its CharsetEncoder encounters an unmappable character in
> the input buffer.
> When its CharsetEncoder encounters an unmappable character, the value of
> CoderResult lastCoderResult.isUnmappable() == true, and Reader.read() is not
> invoked on the underlying Reader ever again.
> Attaching source file that reproduces this behavior.
> One fix to consider is to call
> CharsetEncoder.onUnmappableCharacter(CodingErrorAction) in the
> ReaderInputStream constructor with a value other than the default
> CodingErrorAction.REPORT. e.g.:
> public ReaderInputStream(Reader reader, Charset charset, int bufferSize) {
> this.reader = reader;
> encoder = charset.newEncoder();
> encoder.onUnmappableCharacter(CodingErrorAction.REPLACE);
> ...
> By replacing the unmappable character with encoder's default replacement
> character, this effectively prevents the infinite loop from occurring. I'm
> not sure if that's the ideal behavior, but it seems fairly consistent with
> what org.apache.commons.io.output.WriterOutputStream does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-262) FileAlterationObserver has no getter for FileFilter
[ https://issues.apache.org/jira/browse/IO-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-262. -- Closing, we released version 2.1. > FileAlterationObserver has no getter for FileFilter > --- > > Key: IO-262 > URL: https://issues.apache.org/jira/browse/IO-262 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.0, 2.0.1 >Reporter: Lae >Priority: Trivial > Fix For: 2.1 > > Original Estimate: 5m > Remaining Estimate: 5m > > FileAlterationObserver accepts a FileFilter, but there is no getter for it, > which causes inconvenience when implementing a FileAlterationListener. > For example, when implementing > FileAlterationListener.onStart(FileAlterationObserver), I wanted to get all > existing files under FileAlterationObserver.getDirectory() that satisfies the > FileFilter the user used to construct the observer, so that I can keep track > of present states of the target files as well as their future states. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-282) Add API FileUtils.copyFile(File input, OutputStream output)
[ https://issues.apache.org/jira/browse/IO-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-282. -- Closing, we released version 2.1. > Add API FileUtils.copyFile(File input, OutputStream output) > --- > > Key: IO-282 > URL: https://issues.apache.org/jira/browse/IO-282 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.0.1 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 2.1 > > > Add API FileUtils.copyFile(File input, OutputStream output) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-285) Use standard Maven directory layout.
[ https://issues.apache.org/jira/browse/IO-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-285. -- Closing, we released version 2.1. > Use standard Maven directory layout. > > > Key: IO-285 > URL: https://issues.apache.org/jira/browse/IO-285 > Project: Commons IO > Issue Type: Improvement > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 2.1 > > > Use standard Maven directory layout. The assembly dir should be in src/main. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (IO-284) Add IOUtils API toString for URL and URI to get contents
[ https://issues.apache.org/jira/browse/IO-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-284. -- Closing, we released version 2.1. > Add IOUtils API toString for URL and URI to get contents > > > Key: IO-284 > URL: https://issues.apache.org/jira/browse/IO-284 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.0.1 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.1 > > > Add IOUtils API toString for URL and URI to get contents: > - org.apache.commons.io.IOUtils.toString(URI) > - org.apache.commons.io.IOUtils.toString(URI, String) > - org.apache.commons.io.IOUtils.toString(URL) > - org.apache.commons.io.IOUtils.toString(URL, String) > (This is already in SVN, I am adding this ticket to track this in the release > notes.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
