[jira] Resolved: (CONFIGURATION-308) User Guide overview section has invalid links to API docs
[ https://issues.apache.org/jira/browse/CONFIGURATION-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-308. Resolution: Fixed Fix Version/s: 1.6 Patch applied. Many thanks! > User Guide overview section has invalid links to API docs > - > > Key: CONFIGURATION-308 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-308 > Project: Commons Configuration > Issue Type: Bug > Components: Documentation >Affects Versions: 1.5, 1.6 >Reporter: Feng Wu >Assignee: Oliver Heger >Priority: Trivial > Fix For: 1.6 > > Attachments: overview.xml.patch > > Original Estimate: 0.05h > Remaining Estimate: 0.05h > > overview.xml has the following links to Configuration api doc which leads to > 404: > href="apidocs/org/apache/commons/configuration/Configuration.html">Configuration > They should be changed to: > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
[ https://issues.apache.org/jira/browse/POOL-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Takayuki Kaneko updated POOL-75: Attachment: java2.patch I revised my patch. * integrated with GenericObjectPool, which means removing duplicated operations around maxActive. * fixed a problem around maxWait handling. As a result, GenericObjectPool#borrowObject is simpler. > [pool] GenericObjectPool not FIFO with respect to borrowing threads > --- > > Key: POOL-75 > URL: https://issues.apache.org/jira/browse/POOL-75 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Operating System: All > Platform: All >Reporter: Gordon Mohr >Priority: Minor > Fix For: 1.5 > > Attachments: ctest.fairness.png, ctest.original.png, java.patch, > java2.patch > > > GenericObjectPool has recently been made FIFO with respect to the managed pool > objects -- however, it is still not FIFO with respect to threads requesting > those objects. Specifically, because standard non-fair Java synchronization > monitors are used, later threads may barge ahead of earlier threads that are > already waiting for a pool object to become available. At its extreme, some > threads can cycle objects through the pool many times while others wait > interminable. > Not every application needs FIFO fairness with respect to threads, and such > fairness implies an overhead, so it need not be the default behavior, but it > would be a valuable option where many threads are sharing a smaller number of > pool objects. > I can submit a FairGenericObjectPool which achieves thread-fairness; it only > requires small changes to GenericObjectPool which allow some subclass > overriding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-142) Retrieve Directory File List in Timestamp Order
[ https://issues.apache.org/jira/browse/IO-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-142: --- Attachment: IO-142-listfiles-v1.patch Atttaching a patch which includes 4 new methods in FileUtils: - public static Iterable listFiles(File, FileFilter, Comparator) - public static Iterable listFiles(String, FileFilter, Comparator) - public static Iterable listFilesRecursive(File, FileFilter, Comparator) - public static Iterable listFilesRecursive(String, FileFilter, Comparator) These provide the option to filter an sort the files from either a single directory or recursviely thru the directory structure. Using these with IO's packages of Filters and Comparators implementations, would be pretty powerful: http://commons.apache.org/io/api-release/org/apache/commons/io/filefilter/package-summary.html http://commons.apache.org/io/api-release/org/apache/commons/io/comparator/package-summary.html Needs test cases > Retrieve Directory File List in Timestamp Order > --- > > Key: IO-142 > URL: https://issues.apache.org/jira/browse/IO-142 > Project: Commons IO > Issue Type: New Feature > Components: Utilities > Environment: Java SE 5 - Windows, Linux >Reporter: Al Scherer > Attachments: IO-142-listfiles-v1.patch > > > I searched your current Commons-IO issues/feature requests and did not find > the following so I'd like to propose it as a feature request. > Given a filename filter and dir name, the method would return a List of > the files that match the filter in last-modified timestamp order. > Sun explicitly does not provide this functionality - from the Sun Java SE 5 > API Javadocs, File's listFiles() method descriptions include the following > disclaimer: > "There is no guarantee that the name strings in the resulting array > will appear in any specific order; they are not, in particular, guaranteed to > appear in alphabetical order." > I needed the files in last-modified order so I wrote code to do it and would > be glad to share the code with the commons project if you feel it would be > useful. > The signature is: > - public List getFileListInTimestampOrder(FilenameFilter filter, String > dirName) > I've already written, tested and used code to do this. > There are additional flavors that might be worthwhile, too. > - public List getFileListInTimestampOrderReversed(FilenameFilter > filter, String dirName) > - public List getFileListInNameOrder(FilenameFilter filter, String > dirName) > - public List getFileListInNameOrderReversed(FilenameFilter filter, > String dirName) > BTW, I originally posted this on commons-lang but was given feedback that it > might be a better fit here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[
https://issues.apache.org/jira/browse/IO-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-89.
---
Resolution: Won't Fix
> Inconsistency in SizeFileFilter and AgeFileFilter implementations
> -
>
> Key: IO-89
> URL: https://issues.apache.org/jira/browse/IO-89
> Project: Commons IO
> Issue Type: Bug
> Components: Filters
>Affects Versions: 1.2
>Reporter: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
>
> Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
> AgeFileFilter.
> In SizeFileFilter, using an "acceptLarger" parameter of true actually accepts
> files with a size equal to and larger, whereas
> specifying an "acceptLarger" parameter of false only accepts smaller files.
> The same is true for AgeFileFilter, using an "acceptOlder" parameter of true
> actually accepts files either the same age or older, whereas
> specifying an "acceptOlder" parameter of false only accepts newer files.
> A big benefit of resolving these inconsistencies would mean that creating
> filters for any condition (i.e. <, >, <=, >= or =) becomes
> alot easier. For example if the AgeFileFilter did only do either newer or
> older, then creating a filters for "the same age or older"
> or "the same age or younger" could be done in the following way:
> IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
> false));
> IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
> true));
> For SizeFileFilter I propose changing the logic to the following:
> if (acceptLarger) {
> return file.length() >= size;
> } else {
> return file.length() <= size;
> }
> (This would mean that "new SizeFileFilter(cutoff)" would operate the same way)
> I have added isOlderFile() methods to FileUtils and propose that
> AgeFileFilter is changed to the following:
> if (acceptOlder) {
> return FileUtils.isFileOlder(file, cutoff);
> } else {
> return FileUtils.isFileNewer(file, cutoff);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-154) Throw IllegalArgumentException when parameters are null (and explicitly checked)
[ https://issues.apache.org/jira/browse/IO-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-154. Resolution: Won't Fix Don't think there was any interest in doing this > Throw IllegalArgumentException when parameters are null (and explicitly > checked) > > > Key: IO-154 > URL: https://issues.apache.org/jira/browse/IO-154 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 2.x > > > IO is currently inconsistent with it explicitly throwing either a > NullPointerException or IllegalArgumentException when a methods arguments are > null - see discussion on IO-77. Review and change IO to only explcitly throw > IllegalArgumentException in this scenario. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-140) IO 2.0 - Move to JDK 1.5
[ https://issues.apache.org/jira/browse/IO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-140: --- Fix Version/s: (was: 2.x) 2.0 Summary: IO 2.0 - Move to JDK 1.5 (was: IO 2.0 - remove deprecations and move to JDK 1.5) OK I've applied all the JDK 1.5 changes, except I added the "CharSequence" flavour methods to IOUtils and FileUtils, rather than changing the signature of the existing methods: - Use generics: http://svn.apache.org/viewvc?view=rev&revision=619103 - Use StringBuilder (non-sync) in place of StringBuffer : http://svn.apache.org/viewvc?view=rev&revision=619112 - Add new JDK 1.5 Read/Writer methods: http://svn.apache.org/viewvc?view=rev&revision=619135 - Add CharSequence flavour methods to IOUtils / FileUtils: http://svn.apache.org/viewvc?view=rev&revision=619188 - Replace StringWriter with StringBuilderWriter in IOUtils: http://svn.apache.org/viewvc?view=rev&revision=619195 So far AFAIK none of these are incompatible changes - clirr is only showing an issue with the LineIterator next() method returning a String rather than Object - but I think this is a false positive? Stephen mentioned a couple of other points (Collections to Iterable, and removing arrays) here: http://commons.markmail.org/message/xcplvzf3p4odbckx > IO 2.0 - Move to JDK 1.5 > > > Key: IO-140 > URL: https://issues.apache.org/jira/browse/IO-140 > Project: Commons IO > Issue Type: Wish >Reporter: Niall Pemberton > Fix For: 2.0 > > Attachments: IO-2.0-deprecate-and-jdk5.patch > > > I just created IO-139 for a StringBuilder Writer implementation that requies > JDK 1.5. So I thought I would look at the impact on IO of 1) Removing all > deprecations and 2) Making appropriate JDK 1.5 changes (generics, using > StringBuilder and new Appendable for Writers). Below is a summary, thought it > could be a starting point for discussion about IO 2.0 > 1) DEPRECATIONS > - CopyUtils > - FileCleaner > - WildcardFilter > - FileSystemUtils freeSpace(String) > - IOUtils toByteArray(String), toString(byte[]), toString(byte[], String) > 2) JDK 1.5 > - ConditionalFileFilter List (and also AndFileFilter and OrFileFilter > implementations > - getFileFilters() and setFileFilters() use generic List > - Constructor for NameFileFilter, PrefixFileFilter, SuffixFileFilter, > WildcardFileFilter use generic List > - replace StringBuffer with StringBuilder where appropriate > (FilenameUtils, FileSystemUtils, HexDump,IOUtils > - FileUtils > - convertFileCollectionToFileArray() --> Collection > - listFiles() --> Collection > - listFiles() --> Collection > - writeStringToFile String-->CharSequence (JDK 1.4+) > - ProxyReader - add read(CharBuffer) > - IOUtils > - readLines(Reader) return List > - toInputStream(String) --> toInputStream(CharSequence) (JDK 1.4+) > - write(String data, OutputStream) and write(StringBuffer data, > OutputStream) --> write(CharSequence data, OutputStream) > - write(String, Writer) and write(StringBuffer, Writer) --> > write(CharSequence data, Writer) > - LineIterator Iterator --> Iterator - NullWriter - add "Appendable" methods > - ProxyWriter - add "Appendable" methods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-155) use NIO for copyFile when running on java 1.4
[ https://issues.apache.org/jira/browse/IO-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-155. Resolution: Fixed Fix Version/s: (was: 2.x) 2.0 Assignee: Niall Pemberton Fixed thanks http://svn.apache.org/viewvc?view=rev&revision=619156 > use NIO for copyFile when running on java 1.4 > - > > Key: IO-155 > URL: https://issues.apache.org/jira/browse/IO-155 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.4 >Reporter: nicolas de loof >Assignee: Niall Pemberton >Priority: Trivial > Fix For: 2.0 > > Attachments: IO-155.patch > > > CopyFile can rely on java.nio when runtime is java 1.4 + -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-139) StringBuilder Writer implementation
[ https://issues.apache.org/jira/browse/IO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-139. Resolution: Fixed Fix Version/s: (was: 2.x) 2.0 Fixed: http://svn.apache.org/viewvc?view=rev&revision=619141 > StringBuilder Writer implementation > --- > > Key: IO-139 > URL: https://issues.apache.org/jira/browse/IO-139 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 2.0 > > Attachments: StringBuilderWriter.java, StringBuilderWriterTest.java > > > This implementation, as an alternative to java.io.StringWriter, provides an > un-synchronized (i.e. for use in a single thread) implementation for better > performance. StringBuilder is a JDK 1.5+ feature -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-308) User Guide overview section has invalid links to API docs
User Guide overview section has invalid links to API docs - Key: CONFIGURATION-308 URL: https://issues.apache.org/jira/browse/CONFIGURATION-308 Project: Commons Configuration Issue Type: Bug Components: Documentation Affects Versions: 1.5, 1.6 Reporter: Feng Wu Priority: Trivial Attachments: overview.xml.patch overview.xml has the following links to Configuration api doc which leads to 404: Configuration They should be changed to: -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONFIGURATION-308) User Guide overview section has invalid links to API docs
[ https://issues.apache.org/jira/browse/CONFIGURATION-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feng Wu updated CONFIGURATION-308: -- Attachment: overview.xml.patch patch is attached here. > User Guide overview section has invalid links to API docs > - > > Key: CONFIGURATION-308 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-308 > Project: Commons Configuration > Issue Type: Bug > Components: Documentation >Affects Versions: 1.5, 1.6 >Reporter: Feng Wu >Priority: Trivial > Attachments: overview.xml.patch > > Original Estimate: 0.05h > Remaining Estimate: 0.05h > > overview.xml has the following links to Configuration api doc which leads to > 404: > href="apidocs/org/apache/commons/configuration/Configuration.html">Configuration > They should be changed to: > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-410) Ambiguous / confusing names in StringUtils replace* methods
[ https://issues.apache.org/jira/browse/LANG-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-410: -- Attachment: StringUtils.patch > Ambiguous / confusing names in StringUtils replace* methods > --- > > Key: LANG-410 > URL: https://issues.apache.org/jira/browse/LANG-410 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb >Priority: Minor > Attachments: StringUtils.patch > > > The recently added replaceEach* methods use "repl" for the original string > list, and "with" for the new (replacement) string list. > These names are rather confusing. > RE engines tend to use words such as: > Perl: > searchlist > replacementlist > ORO: > pattern > replacement > Java has String.replace(regex, replacement) > In all cases, "replacement" is used for the NEW string, not the original > string which is to be replaced. > Seems to me that searchString/List and replacement[List] would be unambiguous > as well as descriptive. > Also useful in IDEs which show possible method completions. > Changing the names of the parameters would not affect the API. > Patch to follow -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-410) Ambiguous / confusing names in StringUtils replace* methods
Ambiguous / confusing names in StringUtils replace* methods --- Key: LANG-410 URL: https://issues.apache.org/jira/browse/LANG-410 Project: Commons Lang Issue Type: Bug Reporter: Sebb Priority: Minor The recently added replaceEach* methods use "repl" for the original string list, and "with" for the new (replacement) string list. These names are rather confusing. RE engines tend to use words such as: Perl: searchlist replacementlist ORO: pattern replacement Java has String.replace(regex, replacement) In all cases, "replacement" is used for the NEW string, not the original string which is to be replaced. Seems to me that searchString/List and replacement[List] would be unambiguous as well as descriptive. Also useful in IDEs which show possible method completions. Changing the names of the parameters would not affect the API. Patch to follow -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
[ https://issues.apache.org/jira/browse/LANG-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566211#action_12566211 ] Jörg Gottschling commented on LANG-409: --- Hm,... OK, that's the same. I use StringUtils very much, but I had not seen this already. I just did not associate "blank" with "only Whitespace". My fault. And about the second one: isNotBlank(String string, int length) seams not to be the right naming. I also proposed a method isLength(String string, int length) Perhaps this best solved in conjunction with that method, like that: isNotBlank(string) && isLength(string, 5) Or do "isTextLength" or "isLengthNotBlank" seam to be more useful? > StringUtils.isText to check in a null safe way if a String has (real) text > -- > > Key: LANG-409 > URL: https://issues.apache.org/jira/browse/LANG-409 > Project: Commons Lang > Issue Type: Improvement >Reporter: Jörg Gottschling >Priority: Minor > > I used something similar from the Spring Framework and it was useful. I > suggest two methods where the second is a little more advanced then theirs. > First a method StringUtils.isText(String text) : boolean which checks if the > String is not null and contains a least one not whitespace character. (In > Spring it's "hasText", but "isText" seams to be more consistent within > commons lang.) > The second method could be StringUtils.isText(String text, int n) : boolean > which checks if the String is not null and contains a least n not whitespace > characters. > Question: What happens if a (stupid ;-) developer checks for -5 characters? I > think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
[ https://issues.apache.org/jira/browse/LANG-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566181#action_12566181 ] Gary Gregory commented on LANG-409: --- How is isText(String) different than the current isNotBlank(String)? See the family of methods: isBlank, isEmpty, isNotBlank, isNotEmpty > StringUtils.isText to check in a null safe way if a String has (real) text > -- > > Key: LANG-409 > URL: https://issues.apache.org/jira/browse/LANG-409 > Project: Commons Lang > Issue Type: Improvement >Reporter: Jörg Gottschling >Priority: Minor > > I used something similar from the Spring Framework and it was useful. I > suggest two methods where the second is a little more advanced then theirs. > First a method StringUtils.isText(String text) : boolean which checks if the > String is not null and contains a least one not whitespace character. (In > Spring it's "hasText", but "isText" seams to be more consistent within > commons lang.) > The second method could be StringUtils.isText(String text, int n) : boolean > which checks if the String is not null and contains a least n not whitespace > characters. > Question: What happens if a (stupid ;-) developer checks for -5 characters? I > think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SANDBOX-209) NullPointerException
NullPointerException Key: SANDBOX-209 URL: https://issues.apache.org/jira/browse/SANDBOX-209 Project: Commons Sandbox Issue Type: Bug Components: CSV Affects Versions: Nightly Builds Reporter: Andriy Sholokh Fix For: Nightly Builds If public void print(String value) method of CSVPrinter class gets null parameter it throws NullPointerException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
StringUtils.isText to check in a null safe way if a String has (real) text -- Key: LANG-409 URL: https://issues.apache.org/jira/browse/LANG-409 Project: Commons Lang Issue Type: Improvement Reporter: Jörg Gottschling Priority: Minor I used something similar from the Spring Framework and it was useful. I suggest two methods where the second is a little more advanced then theirs. First a method StringUtils.isText(String text) : boolean which checks if the String is not null and contains a least one not whitespace character. (In Spring it's "hasText", but "isText" seams to be more consistent within commons lang.) The second method could be StringUtils.isText(String text, int n) : boolean which checks if the String is not null and contains a least n not whitespace characters. Question: What happens if a (stupid ;-) developer checks for -5 characters? I think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-408) StringUtils.isLength(String string, int length) : boolean
StringUtils.isLength(String string, int length) : boolean - Key: LANG-408 URL: https://issues.apache.org/jira/browse/LANG-408 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Jörg Gottschling Priority: Minor Just a null safe way to check the length of an String. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
