[jira] Commented: (COLLECTIONS-259) TransformerClosure should implement Transformer and allow extension.
[
https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512402
]
Stephen Colebourne commented on COLLECTIONS-259:
My preference would be to see the Predicate/Transformer/Closure parts of
[collections-generics] separated into a separate jar/project, as I don't think
that they are the main focus of interest for [collections]. Then, I think
adding new constructors/methods like this would have less impact (eg. on jar
file size of the main [collections] jar)
TransformerClosure should implement Transformer and allow extension.
Key: COLLECTIONS-259
URL: https://issues.apache.org/jira/browse/COLLECTIONS-259
Project: Commons Collections
Issue Type: Improvement
Components: Functor
Affects Versions: 3.2
Reporter: Stephen Kestle
Priority: Minor
Fix For: 3.3, Generics
TransformerClosure currently decorates a transformer. However, in the
interests of non-verbose code, it makes sense to be able to subclass it for a
class that implements both interfaces.
I propose the addition of the following constructor and method
protected TransformerClosure(){
iTransformer = this;
}
public O transform(I in){
return iTransformer.transform();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-259) TransformerClosure should implement Transformer and allow extension.
[
https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511686
]
Stephen Colebourne commented on COLLECTIONS-259:
An interesting idea, however I sense that it might confuse the intent of the
class for a limited use case.
TransformerClosure should implement Transformer and allow extension.
Key: COLLECTIONS-259
URL: https://issues.apache.org/jira/browse/COLLECTIONS-259
Project: Commons Collections
Issue Type: Improvement
Components: Functor
Affects Versions: 3.2
Reporter: Stephen Kestle
Priority: Minor
Fix For: 3.3, Generics
TransformerClosure currently decorates a transformer. However, in the
interests of non-verbose code, it makes sense to be able to subclass it for a
class that implements both interfaces.
I propose the addition of the following constructor and method
protected TransformerClosure(){
iTransformer = this;
}
public O transform(I in){
return iTransformer.transform();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
[ https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509269 ] Stephen Colebourne commented on BEANUTILS-285: -- Although I haven't followed the detail of this case, ensuring it is fully semantically, binary and source compatible is essential IMO. These are exceptionally widely distributed libraries, and having anything change in them that breaks others will create all sorts of dependency hell. Maybe the better solution here is to get commons-convert working and released, as a simple object-string conversion tool (the original plan), and then allow [beanutils] to optionally use [convert] as the conversion provider instead of the old (rolled back) converters in [beanutils] ? Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Attachments: betwixt-beanutils-gump-fix.patch The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509270 ] Stephen Colebourne commented on LANG-326: - Personally, I would go with 2.4. StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509193 ] Stephen Colebourne commented on LANG-326: - I'm happy for these ignoreCase methods to be added. For collators I'd suggest a CollatorUtils. StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-123) LineIterator should call close on itself when hasNext() returns false.
[
https://issues.apache.org/jira/browse/IO-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506338
]
Stephen Colebourne commented on IO-123:
---
Unfortunately, if the block of code within the loop throws an exception, then
the file isn't closed.
LineIterator should call close on itself when hasNext() returns false.
--
Key: IO-123
URL: https://issues.apache.org/jira/browse/IO-123
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.3.1
Reporter: Dalibor Novak
Priority: Minor
Fix For: 1.3.2
LineIterator should call close on itself when hasNext() returns false. This
would enable us to write something like this:
for (LineIterator lit = FileUtils.lineIterator(csvFile); lit.hasNext(); )
{
//do something
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-255) Unused variable in TreeBidiMap.java
[ https://issues.apache.org/jira/browse/COLLECTIONS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502770 ] Stephen Colebourne commented on COLLECTIONS-255: As a general rule, collections implementations use (b). Unused variable in TreeBidiMap.java --- Key: COLLECTIONS-255 URL: https://issues.apache.org/jira/browse/COLLECTIONS-255 Project: Commons Collections Issue Type: Bug Components: BidiMap Affects Versions: Nightly Builds Reporter: Henri Yandell Priority: Trivial Fix For: 3.3 Twice in TreeBidiMap there is an entrySet variable that is not used. Rather the entrySet() method returns a new TreeView every time. We should either: a) Delete the variable. b) Use the variable and always return the same TreeView. I'm thinking a). [Found via http://opensource.fortifysoftware.com/ ] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-335) Comparisons of Dates and Calendars to second precision
[ https://issues.apache.org/jira/browse/LANG-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497837 ] Stephen Colebourne commented on LANG-335: - Joda-Time, DateTimeComparator Comparisons of Dates and Calendars to second precision -- Key: LANG-335 URL: https://issues.apache.org/jira/browse/LANG-335 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Environment: Windows, JDK 1.6.0, Eclipse 3.2 Reporter: Alex Marshall Priority: Trivial The o.a.c.lang.time.DateUtils should have functions for comparing dates and Calendars to only second precision instead of millisecond. The motivation for this is comparison of dates and Calendars in objects both before and after the objects have been committed to and retrieved from a database. In theory the objects should be equal if 'equals' is run on them, but in practice they are not because the date fields do not have exactly the same millisecond values after they've been persisted to a database since times in many databases are only maintained to second-level precision (and without TimeZone information in many cases, to boot!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-231) Not return the base interface on decorate
[ https://issues.apache.org/jira/browse/COLLECTIONS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493501 ] Stephen Colebourne commented on COLLECTIONS-231: This change cannot be made as changing the return type is binary incompatible. The constructor is not public as it has a different meaning to a constructor taking a map on a HashMap (decorate vs copy). Not return the base interface on decorate - Key: COLLECTIONS-231 URL: https://issues.apache.org/jira/browse/COLLECTIONS-231 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: 3.2 Reporter: Torsten Curdt Fix For: 3.3 At the moment I don't see a reason why the static decorate method does not return ListOrderedMap but just the base interface OrderedMap. I want to decorate a Map to be a ListOrderedMap but due to the fact that the constructor is not visible and decorate only returns the base interface OrderedMap an unnecessary cast is required. ListOrderedMap map = (ListOrderedMap)ListOrderedMap.decorate(new MyMap()); As the decorate method is static and not part of any interface it should be fine to return the real type instead of the base. Otherwise I'd suggest to make the constructor visible. From the API POV It is not really understandable why this ListOrderedMap map = new ListOrderedMap(); is fine and creates a HashMap under the hood while this ListOrderedMap map = new ListOrderedMap(new MyMap())); is not ok. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489332 ] Stephen Colebourne commented on LANG-326: - Is there a role for CaseInsensitiveStringUtils instead? How many of these methods need adding? StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-243) Generic versions of Predicated, Syncronized and Unmodifiable classes
[ https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated COLLECTIONS-243: --- Component/s: Set List Bag Summary: Generic versions of Predicated, Syncronized and Unmodifiable classes (was: generic versions of some more classes) Generic versions of Predicated, Syncronized and Unmodifiable classes Key: COLLECTIONS-243 URL: https://issues.apache.org/jira/browse/COLLECTIONS-243 Project: Commons Collections Issue Type: Improvement Components: Bag, Collection, List, Set Affects Versions: Generics Environment: OS X Reporter: Edwin Tellman Priority: Minor Fix For: Generics Attachments: collections_06_03_11.patch I added generics to some more classes and fixed some compilation problems. The generic version of Transformer required the input and output types to be identical. This seemed to me to reduce the usefulness of transformed collections, as transforming one type into another seems like it would be a fairly common operation. I'm not sure how to fix this, however, as it also doesn't seem feasible to have a generic TransformedCollection with different input and output types that implements CollectionE. Anyway, this patch de-generifies TransformedCollection, which also fixes some compilation problems. Please disregard this change if you disagree and have a better solution. The modified collection classes are: Bags: PredicatedSortedBag, AbstractBagDecorator, SynchronizedBag, UnmodifiableSortedBag, SynchronizedSortedBag, PredicatedBag Lists: PredicatedList, SynchronizedList Sets: PredicatedSortedSet, SynchronizedSortedSet, PredicatedSet, UnmodifiableSortedSet, SynchronizedSet Miscellaneous: PredicatedBuffer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-110) Support parametized classes with commons.collections.
[ https://issues.apache.org/jira/browse/COLLECTIONS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481929 ] Stephen Colebourne commented on COLLECTIONS-110: Note for the implementation of generics. List implementations need to consider whether they should implement the JDK interface 'RandomAccess'. Support parametized classes with commons.collections. - Key: COLLECTIONS-110 URL: https://issues.apache.org/jira/browse/COLLECTIONS-110 Project: Commons Collections Issue Type: Wish Environment: Operating System: other Platform: Other Reporter: Colbert Philippe Fix For: Generics It's time to create a parallel version of commons.collections to support parametized classes of each container class and abstract class. It's not that hard. There is a 23 PDF document on Sun Java website describing in detail how it should be done and what to watch out for. I already converted a few classes from commons.collection privately for my own needs. Once you get the hang of it, it's a rather quick process. I am even willing to volunteer my time to do some more but I need the collaboration of some of the original programmers to watch over things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-243) generic versions of some more classes
[ https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480199 ] Stephen Colebourne commented on COLLECTIONS-243: With all of these cases, you also need to ask if there really are any valid use cases for the collection - TransformedXxx in this case. generic versions of some more classes - Key: COLLECTIONS-243 URL: https://issues.apache.org/jira/browse/COLLECTIONS-243 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: Generics Environment: OS X Reporter: Edwin Tellman Priority: Minor Fix For: Generics Attachments: collections_06_03_11.patch I added generics to some more classes and fixed some compilation problems. The generic version of Transformer required the input and output types to be identical. This seemed to me to reduce the usefulness of transformed collections, as transforming one type into another seems like it would be a fairly common operation. I'm not sure how to fix this, however, as it also doesn't seem feasible to have a generic TransformedCollection with different input and output types that implements CollectionE. Anyway, this patch de-generifies TransformedCollection, which also fixes some compilation problems. Please disregard this change if you disagree and have a better solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-242) Add Equator interface for more powerful collections
[ https://issues.apache.org/jira/browse/COLLECTIONS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479762 ] Stephen Colebourne commented on COLLECTIONS-242: I think such an interface is a useful extension to the collections framework. Add Equator interface for more powerful collections --- Key: COLLECTIONS-242 URL: https://issues.apache.org/jira/browse/COLLECTIONS-242 Project: Commons Collections Issue Type: Improvement Components: Comparator Reporter: Stephen Kestle Fix For: Generics Java has Comparable and Comparator to compare objects, and objects have an equals() method. But there is no interface for when an object has multiple ways of being equal. e.g.: an database object that has a name, code and a value. Equality could be based on: * database id * code * name and code * case-insensitive name When extended to collections, this allows us to search for specific values (with an EqualsPredicate that takes an Equator), and implement Maps and Sets that use specific equators to determine uniqueness. I propose that it has two methods: boolean equate(); int hash(); I shall upload some files when I next get some time. NB: This ticket is a summary of the email conversation begun on 5 Jan 2007: equator interface (http://archives.devshed.com/forums/java-118/equator-interface-2126195.html). Stephen C made reference there to creating a FlexiMap, but in my mind, that's additional to this issue (this interface still needs to be created to be able to stand alone). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471523 ] Stephen Colebourne commented on IO-113: --- I think that we can probably get away with option (b) if we are quick enough. FileUtils.readFileToString is not static Key: IO-113 URL: https://issues.apache.org/jira/browse/IO-113 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3 Reporter: Raul Acevedo Fix For: 1.4 FileUtils.readFileToString isn't static. It should be; since the constructor for FileUtils says Instances should NOT be constructed in standard programming, this makes readFileToString unusable. Right now I'm using FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471117 ] Stephen Colebourne commented on IO-113: --- Problem is that the fix is binary incompatible :-( It is source compatible though. Two choices: a) use a different method name b) produce 1.3.1 now with the binary incompatible change as 1.3 was only just completed FileUtils.readFileToString is not static Key: IO-113 URL: https://issues.apache.org/jira/browse/IO-113 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3 Reporter: Raul Acevedo Fix For: 1.4 FileUtils.readFileToString isn't static. It should be; since the constructor for FileUtils says Instances should NOT be constructed in standard programming, this makes readFileToString unusable. Right now I'm using FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-109) FileSystemUtils freeSpaceUnix does not work for HP-UX 11
[
https://issues.apache.org/jira/browse/IO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467701
]
Stephen Colebourne commented on IO-109:
---
The new IO v1.3 release is going to use -kP. Let us know if this works.
FileSystemUtils freeSpaceUnix does not work for HP-UX 11
Key: IO-109
URL: https://issues.apache.org/jira/browse/IO-109
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 1.2
Environment: uname -a
HP-UX mbfwdv B.11.11 U 9000/800 3509210950 unlimited-user license
Reporter: Christopher Olsen
Attachments: FileSystemUtils-HP-UX.fix
The freeSpaceUnix method does not work under HP-UX. The df command under
HP-UX is the old System V varient and the fields are not in the correct
order. This diff modifies the code to use the 'bdf' command when HP-UX is
detected:
--- FileSystemUtils.java2006-03-19 12:42:48.0 -0800
+++ FileSystemUtils-HP-UX-Fix.java 2007-01-11 13:05:34.844269000 -0800
@@ -51,13 +51,15 @@
private static final int WINDOWS = 1;
/** Operating system state flag for Unix. */
private static final int UNIX = 2;
+/** Unix variant name */
+ private static String osName = null;
/** The operating system flag. */
private static final int OS;
static {
int os = OTHER;
try {
-String osName = System.getProperty(os.name);
+osName = System.getProperty(os.name);
if (osName == null) {
throw new IOException(os.name not found);
}
@@ -287,9 +289,18 @@
}
path = FilenameUtils.normalize(path);
+ // HP-UX sucks we need to use bdf instead
+ String dfCmd = df;
+ String dfOpts = -k;
+ if (osName.indexOf(hp-ux) != -1)
+ {
+ dfCmd = bdf;
+ dfOpts = ;
+ }
+
// build and run the 'dir' command
String[] cmdAttribs =
-(kb ? new String[] {df, -k, path} : new String[] {df,
path});
+(kb ? new String[] {dfCmd, dfOpts, path} : new String[] {dfCmd,
path});
// read the output from the command until we come to the second line
long bytes = -1;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-306) Extra StrBuilder methods
[ https://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated LANG-306: Attachment: lang.patch Extra StrBuilder methods Key: LANG-306 URL: https://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: lang.patch, StrBuilder.java Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-310) BooleanUtils isNotTrue/isNotFalse
BooleanUtils isNotTrue/isNotFalse - Key: LANG-310 URL: https://issues.apache.org/jira/browse/LANG-310 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Priority: Minor Fix For: 2.3 Add two methods to BooleanUtils - isNotTrue - isNotFalse These make writing if statements a lot clearer when handling nulls. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LANG-310) BooleanUtils isNotTrue/isNotFalse
[ https://issues.apache.org/jira/browse/LANG-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-310. --- Resolution: Fixed svn commit C:\dev\commons\lang\RELEASE-NOTES.txt C:\dev\commons\lang\src\java\org\apache\commons\lang\BooleanUtils.java C:\dev\commons\lang\src\test\org\apache\commons\lang\BooleanUtilsTest.java -N -m LANG-310 - BooleanUtils isNotTrue/isNotFalse --username scolebourne M C:\dev\commons\lang\RELEASE-NOTES.txt M C:\dev\commons\lang\src\java\org\apache\commons\lang\BooleanUtils.java M C:\dev\commons\lang\src\test\org\apache\commons\lang\BooleanUtilsTest.java Transmitting file data: C:\dev\commons\lang\RELEASE-NOTES.txt Transmitting file data: C:\dev\commons\lang\src\java\org\apache\commons\lang\BooleanUtils.java Transmitting file data: C:\dev\commons\lang\src\test\org\apache\commons\lang\BooleanUtilsTest.java Committed revision 492361 * BooleanUtils isNotTrue/isNotFalse - Key: LANG-310 URL: https://issues.apache.org/jira/browse/LANG-310 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Priority: Minor Fix For: 2.3 Add two methods to BooleanUtils - isNotTrue - isNotFalse These make writing if statements a lot clearer when handling nulls. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LANG-306) Extra StrBuilder methods
[ https://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-306. --- Resolution: Fixed Assignee: Stephen Colebourne svn commit C:\dev\commons\lang\RELEASE-NOTES.txt C:\dev\commons\lang\src\java\org\apache\commons\lang\text\StrBuilder.java C:\dev\commons\lang\src\test\org\apache\commons\lang\text\StrBuilderAppendInsertTest.java -N -m LANG-306 - StrBuilder appendln/appendAll/appendSeparator --username scolebourne M C:\dev\commons\lang\RELEASE-NOTES.txt M C:\dev\commons\lang\src\java\org\apache\commons\lang\text\StrBuilder.java M C:\dev\commons\lang\src\test\org\apache\commons\lang\text\StrBuilderAppendInsertTest.java Transmitting file data: C:\dev\commons\lang\RELEASE-NOTES.txt Transmitting file data: C:\dev\commons\lang\src\java\org\apache\commons\lang\text\StrBuilder.java Transmitting file data: C:\dev\commons\lang\src\test\org\apache\commons\lang\text\StrBuilderAppendInsertTest.java Committed revision 492369 Extra StrBuilder methods Key: LANG-306 URL: https://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: lang.patch, StrBuilder.java Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LANG-275) Add a pair of StringUtils.substringsBetween;String[] methods
[ https://issues.apache.org/jira/browse/LANG-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne closed LANG-275. --- Resolution: Fixed Fix Version/s: (was: 3.0) 2.3 Assignee: Stephen Colebourne svn commit C:\dev\commons\lang\RELEASE-NOTES.txt C:\dev\commons\lang\project.xml C:\dev\commons\lang\src\java\org\apache\commons\lang\StringUtils.java C:\dev\commons\lang\src\test\org\apache\commons\lang\StringUtilsSubstringTest.java -N -m LANG-275 - StringUtils substringsBetween, implemented by Dave Meikle --username scolebourne M C:\dev\commons\lang\RELEASE-NOTES.txt M C:\dev\commons\lang\project.xml M C:\dev\commons\lang\src\java\org\apache\commons\lang\StringUtils.java M C:\dev\commons\lang\src\test\org\apache\commons\lang\StringUtilsSubstringTest.java Transmitting file data: C:\dev\commons\lang\RELEASE-NOTES.txt Transmitting file data: C:\dev\commons\lang\project.xml Transmitting file data: C:\dev\commons\lang\src\java\org\apache\commons\lang\StringUtils.java Transmitting file data: C:\dev\commons\lang\src\test\org\apache\commons\lang\StringUtilsSubstringTest.java Committed revision 492377 Add a pair of StringUtils.substringsBetween;String[] methods Key: LANG-275 URL: https://issues.apache.org/jira/browse/LANG-275 Project: Commons Lang Issue Type: Wish Reporter: Henri Yandell Assigned To: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: LANG-275.patch I found myself wanting a version of substringBetween(String, String, String) that would return a String[] of the ones between and not just the single String for the first match. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-309) Add ArrayUtils.addFirst methods.
[ https://issues.apache.org/jira/browse/LANG-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462109 ] Stephen Colebourne commented on LANG-309: - The problem with the arrays methods is that there are a lot of them. Personally, this one doesn't rock my boat, as writing '0' comes pretty naturally. And I'd say that inserting an item at the start of an array is probably pretty rare anyway. Add ArrayUtils.addFirst methods. Key: LANG-309 URL: https://issues.apache.org/jira/browse/LANG-309 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.2 Reporter: Gary Gregory Priority: Minor Add ArrayUtils.addFirst methods? This is pretty trivial, implementation wise. I'd like some feedback before implementation. For example, is ArrayUtils.addFirst (array, newFirstElement); really better than: ArrayUtils.add(array, 0, newFirstElement); ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-306) Extra StrBuilder methods
Extra StrBuilder methods Key: LANG-306 URL: http://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 2.3 Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-306) Extra StrBuilder methods
[ http://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Colebourne updated LANG-306: Attachment: StrBuilder.java Extra StrBuilder methods Key: LANG-306 URL: http://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: StrBuilder.java Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-306) Extra StrBuilder methods
[ http://issues.apache.org/jira/browse/LANG-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461869 ] Stephen Colebourne commented on LANG-306: - Decision of the Release Manager. I wasn't expecting that they would make it in. Especially as they don't have tests yet, and its late... Extra StrBuilder methods Key: LANG-306 URL: http://issues.apache.org/jira/browse/LANG-306 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 2.3 Attachments: StrBuilder.java Append all the elements in a collection with no separator: StrBuilder.appendAll(Collection) StrBuilder.appendAll(Object[]) StrBuilder.appendAll(Iterator) Append the data followed by a new line: StrBuilder.appendln(...) Append a separator if the buffer is not empty: StrBuilder.appendSeparator(String) Append a separator if the index 0: StrBuilder.appendSeparator(String, index) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-238) [lang] Add equals(type[]) to NumberUtils
[ http://issues.apache.org/jira/browse/LANG-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461614 ] Stephen Colebourne commented on LANG-238: - This newly defined method seems a little unusual - is it really a generic use case? How often do you need to test that all elements in an array are the same? A more general related method might be: containsOnly(arrayToTest, arrayOfPermittedValues) [lang] Add equals(type[]) to NumberUtils Key: LANG-238 URL: http://issues.apache.org/jira/browse/LANG-238 Project: Commons Lang Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: other Platform: Other Reporter: Paul Benedict Priority: Minor Fix For: 3.0 It would be useful to add an equals() method like the current min and max methods which take an array type and determine if all the values are equal. I have found myself in need of this often. I have to retrieve objects from multiple data sources in parallel to build an array of complex object. To ensure validity, I always compare that my sub-retrievals returned the same number of objects as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-99) FileCleaner thread never ends and cause memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=all ] Stephen Colebourne resolved IO-99. -- Resolution: Fixed Assignee: Stephen Colebourne I took a look at getTrackerCount(), but its already synchronized because the list is a Vector. I added a few comments about synchronization to the file to help clarify. Closing the call as fixed. FileCleaner thread never ends and cause memory leak in AS - Key: IO-99 URL: http://issues.apache.org/jira/browse/IO-99 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: JBOssPortal with commons.fileupload Reporter: Vera Mickaël Assigned To: Stephen Colebourne Priority: Critical Fix For: 1.3 Attachments: IO-99.patch FileCleaner opens a thread and no solution is given to the user to end it. So when an application is undeployed in an Application Server, a thread is still alive. The WebApp can't be undeployed and this results in a classloader leak that will cause an OutOfMemoryError. I think the API should be extended so that a user can end the thread. A better way would be to provide a class that cleans everything for commons IO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-97) Trivial performance improvements to ByteArrayOutputStream
[ http://issues.apache.org/jira/browse/IO-97?page=all ] Stephen Colebourne resolved IO-97. -- Fix Version/s: 1.3 (was: 1.4) Resolution: Fixed Assignee: Stephen Colebourne Trivial performance improvements to ByteArrayOutputStream - Key: IO-97 URL: http://issues.apache.org/jira/browse/IO-97 Project: Commons IO Issue Type: Improvement Components: Streams/Writers Affects Versions: 1.2 Reporter: Holger Hoffstätte Assigned To: Stephen Colebourne Fix For: 1.3 Attachments: BAOS.patch Found a few trivial ways to improve performance in ByteArrayOutputStream by fast paths: - write(int) does not have to be synchronized - write(byte[]..) does not have to be synchronized as a whole either; it's enough to synchonize the code that follows the first paramter-checking if-then statement (so parameter checks can pop out quickly) - toByteArray() could just check if count == 0 and quickly return an empty static final byte[] instead of returning a new zero-sized one, doing useless System.arraycopy() etc. A somewhat more involved optimization would be to implement write(int) without the new byte[1] since just poking the byte into the right page is going to be much faster than what happens in write(byte[]..); I'll see if I can do a patch for that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (LANG-238) [lang] Add equals(type[]) to NumberUtils
[ http://issues.apache.org/jira/browse/LANG-238?page=all ] Stephen Colebourne reopened LANG-238: - These methods exist in the JDK in Arrays. We shouldn't duplicate that code unless we've got a good reason. [lang] Add equals(type[]) to NumberUtils Key: LANG-238 URL: http://issues.apache.org/jira/browse/LANG-238 Project: Commons Lang Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: other Platform: Other Reporter: Paul Benedict Priority: Minor Fix For: 2.3 It would be useful to add an equals() method like the current min and max methods which take an array type and determine if all the values are equal. I have found myself in need of this often. I have to retrieve objects from multiple data sources in parallel to build an array of complex object. To ensure validity, I always compare that my sub-retrievals returned the same number of objects as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LANG-305) Deprecate methods found in the JDK 1.5/1.6?
[ http://issues.apache.org/jira/browse/LANG-305?page=all ] Stephen Colebourne resolved LANG-305. - Fix Version/s: (was: 2.3) Resolution: Won't Fix Deprecate methods found in the JDK 1.5/1.6? --- Key: LANG-305 URL: http://issues.apache.org/jira/browse/LANG-305 Project: Commons Lang Issue Type: Task Affects Versions: 2.2 Reporter: Henri Yandell Not too sure on this one - but it seems to me that it would be a good time to deprecate the methods that now have replacements in the standard Java libraries. We could also consider deprecating methods that have replacements in Joda Time. This would allow us to consider removing them in 3.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LANG-301) Unnecessary code in StrTokenizer
[ http://issues.apache.org/jira/browse/LANG-301?page=all ]
Stephen Colebourne resolved LANG-301.
-
Fix Version/s: (was: 3.0)
Resolution: Invalid
The cloneReset() method exists to enable testing.
The return null should never happen, as super.clone() should succeed. Its
really just a way around the JDK flaw of the exception not being a runtime
exception.
Unnecessary code in StrTokenizer
Key: LANG-301
URL: http://issues.apache.org/jira/browse/LANG-301
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2
Reporter: Henri Yandell
In StrTokenizer, we have the following:
1086 public Object clone() {
1087 try {
1088 return cloneReset();
1089 } catch (CloneNotSupportedException ex) {
1090 return null;
1091 }
1092 }
...
1101 Object cloneReset() throws CloneNotSupportedException {
1102 StrTokenizer cloned = (StrTokenizer) super.clone();
1103 if (cloned.chars != null) {
1104 cloned.chars = (char[]) cloned.chars.clone();
1105 }
1106 cloned.reset();
1107 return cloned;
1108 }
FindBugs just reported it because the clone() method doesn't call
super.clone(). While that's not a worry (because the method it calls does), I
don't understand why we're not just doing:
public Object clone() {
StrTokenizer cloned = (StrTokenizer) super.clone();
if (cloned.chars != null) {
cloned.chars = (char[]) cloned.chars.clone();
}
cloned.reset();
return cloned;
}
and why we return null and not a runtime CloneNotSupportedException.
Also, is there any value in StrTokenizer being Cloneable? Or is it just done
for the sake of the getXxxInstance methods?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-284) TextTable for printing a fixedlength columns format text tables
[ http://issues.apache.org/jira/browse/LANG-284?page=comments#action_12461421 ] Stephen Colebourne commented on LANG-284: - I never commented on this at the time. I personally think this is out of scope for [lang]. It has the potential to expand in any number of directions, and has no simple correct implementation. TextTable for printing a fixedlength columns format text tables --- Key: LANG-284 URL: http://issues.apache.org/jira/browse/LANG-284 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.2 Reporter: David Leal Fix For: 3.0 Attachments: TestTextTable.java, TestTextTable.out, TextTable.java Just to suggest adding a TextTable class for printing in text (ASCII) format fixed columns table. It is usefull for printing information from command line application, that informs about directly on DOS Windows of Xterm direclty. I am adding a patch a possible solution for that, Thanks, David -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-286) Serialization - not backwards compatible
[ http://issues.apache.org/jira/browse/LANG-286?page=all ] Stephen Colebourne updated LANG-286: Summary: Serialization - not backwards compatible (was: Not backwards compatible) Changed issue title Serialization - not backwards compatible Key: LANG-286 URL: http://issues.apache.org/jira/browse/LANG-286 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: N/A Reporter: David J. M. Karlsen Fix For: 2.3 Release report states that commons-lang 2.2 is binary backwards compatible, this does not seem to be correct between commons-lang 2.1 and 2.2 Running 2.2 at the server and 2.1 on client will result in an exception: org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Mismatched serialization UIDs : Source (Rep. IDRMI:org.apache.commons.lang.exception.NestableDelegate:4F998DA78EFC2530:F68F1455DDEE96BB) = F68F1455DDEE96BB whereas Target (Rep. ID RMI:org.apache.commons.lang.exception.NestableDelegate:4F998DA78EFC2530:0001) = 0001 minor code: 4942F89A completed: No -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-283) Visitors for Builders
[
http://issues.apache.org/jira/browse/LANG-283?page=comments#action_12461426 ]
Stephen Colebourne commented on LANG-283:
-
This looks very clever, but is probably beyond that which the builders were
originally intended for.
Visitors for Builders
-
Key: LANG-283
URL: http://issues.apache.org/jira/browse/LANG-283
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.2
Environment: Any
Reporter: Aldrin Leal
Priority: Trivial
Fix For: 3.0
Attachments: visitors.patch
While doing commons-lang stuff, I found the repetitive nature of
Builder stuff. Therefore, i decided to:
a) Create a SingleBuilder (for ToString / HashCode) and a
DualBuilder (CompareTo / Equals) interface, and make their classes
implementing;
b) Create a SingleBuilderVisitor and DualBuilderVisitor;
c) Do the proper wiring, while creating new constructors using the visitors;
d) Create new tests and ensuring javadoc plays nice along;
There's a patch attached in this e-mail, done against the latest
svn STABLE url for 2.2
(http://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_2_X/)
There might be errors, but methinks it's a great idea to declare a
constant like this in your source code.
private static final EQUALS_VISITOR = new DualBuilderVisitor() {
public void visit(DualBuilder builder, Object lhs, Object rhs) {
Type lhsObj = (Type) lhs;
Type rhsObj = (Type) rhs;
builder.append(lhsObj.getId(),
rhsObj.getId()).append(lhsObj.getName(), rhsObj.getName());
}
};
And then, declare and instantiate builders like as, say:
public boolean equals(Object anotherObj) {
return new EqualsVisitor(EQUALS_VISITOR, this, anotherObj);
}
Please note this implementation, overrall, also lets you easily use
a single visitor for either equals and compareto, thus creating a
single point of management for all your
field-maintenance-in-value-objects-needs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LANG-52) [lang] Validate.notNull should throw NullArgumentException
[ http://issues.apache.org/jira/browse/LANG-52?page=all ] Stephen Colebourne resolved LANG-52. Fix Version/s: (was: 3.0) Resolution: Won't Fix Yes, this method probably should have thrown NullArgumentException, but it doesn't and its too late to fix now. Also, the JDK should have has a NullArgumentException, but there's not much we can do about that either. [lang] Validate.notNull should throw NullArgumentException -- Key: LANG-52 URL: http://issues.apache.org/jira/browse/LANG-52 Project: Commons Lang Issue Type: Bug Environment: Operating System: All Platform: All Reporter: Jörg Gottschling Priority: Trivial Attachments: LANG-52.patch Validate.notNull throws a IllegalArgumentException but should throw a NullArgumentException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-105) Add a FileUtils.copyDirectoryStructure method
[ http://issues.apache.org/jira/browse/IO-105?page=all ] Stephen Colebourne updated IO-105: -- Fix Version/s: 1.4 Description: For potential source, see: https://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/FileUtils.java (was: For potential source, see: https://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/FileUtils.java) Perhaps you could describe what the method is supposed to do? Add a FileUtils.copyDirectoryStructure method - Key: IO-105 URL: http://issues.apache.org/jira/browse/IO-105 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: Henri Yandell Fix For: 1.4 For potential source, see: https://svn.codehaus.org/plexus/plexus-utils/trunk/src/main/java/org/codehaus/plexus/util/FileUtils.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-103) commons-io cannot be deployed with Maven 2
[ http://issues.apache.org/jira/browse/IO-103?page=all ] Stephen Colebourne resolved IO-103. --- Resolution: Fixed Assignee: Henri Yandell I don't use Maven2, but this change appears to have been committed. commons-io cannot be deployed with Maven 2 -- Key: IO-103 URL: http://issues.apache.org/jira/browse/IO-103 Project: Commons IO Issue Type: Bug Affects Versions: 1.3 Reporter: Jochen Wiedmann Assigned To: Henri Yandell Fix For: 1.3 Attachments: commons-io-resources.patch The commons-io POM contains a resource section, which specifies that the NOTICE.txt and LICENSE.txt files are being added to the jar files META-INF directory. Unfortunately, this triggers MSOURCES-6, a well known bug in the maven-sources-plugin, which attempts to include the base directory into the source jar file. The base directory includes the sources jar itself, which is growing while it is being included into itself, which is growing while it is included into itself, ... In other words, the maven-sources-plugin is creating a jar file endleseely. When deploying the commons-io with mvn -Prc commons-io deploy or mvn -Prelease commons-io deploy then the maven-sources-plugin is invoked by the commons-parent POM. In other words, the commons-io jar file cannot be deployed. The attached patch removes the resources section from the commons-parent POM: This can easily be done, because the commons-parent POM is already addressing this by invoking the antrun plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (IO-107) FileUtils.openOutputStream
FileUtils.openOutputStream -- Key: IO-107 URL: http://issues.apache.org/jira/browse/IO-107 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Fix For: 1.3 Add a new method - FileUtils.openOutputStream. This will centralise the opening of a file in a single place in the source code. The new method will check that the file is not a directory, and will create parent directories if required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-107) FileUtils.openOutputStream
[ http://issues.apache.org/jira/browse/IO-107?page=all ] Stephen Colebourne resolved IO-107. --- Resolution: Fixed FileUtils.openOutputStream -- Key: IO-107 URL: http://issues.apache.org/jira/browse/IO-107 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Fix For: 1.3 Add a new method - FileUtils.openOutputStream. This will centralise the opening of a file in a single place in the source code. The new method will check that the file is not a directory, and will create parent directories if required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-107) FileUtils.openOutputStream
[ http://issues.apache.org/jira/browse/IO-107?page=comments#action_12461270 ] Stephen Colebourne commented on IO-107: --- This call is also being used to add the 'create parent folders' behaviour to other methods in FileUtils. See the release notes for details. FileUtils.openOutputStream -- Key: IO-107 URL: http://issues.apache.org/jira/browse/IO-107 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Fix For: 1.3 Add a new method - FileUtils.openOutputStream. This will centralise the opening of a file in a single place in the source code. The new method will check that the file is not a directory, and will create parent directories if required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-305) Deprecate methods found in the JDK 1.5/1.6?
[ http://issues.apache.org/jira/browse/LANG-305?page=comments#action_12461060 ] Stephen Colebourne commented on LANG-305: - I am opposed to this. [lang] provides lots of stuff that is still useful despite later versions of the JDK. StrBuilder cannot be replaced by StringBuilder as it has much more functionality. So do our enums. So do the static methods. I don't see vast benefits in generics either in [lang]. It would help in a few places, but whether its enough to justify it is questionable. Deprecate methods found in the JDK 1.5/1.6? --- Key: LANG-305 URL: http://issues.apache.org/jira/browse/LANG-305 Project: Commons Lang Issue Type: Task Affects Versions: 2.2 Reporter: Henri Yandell Fix For: 2.3 Not too sure on this one - but it seems to me that it would be a good time to deprecate the methods that now have replacements in the standard Java libraries. We could also consider deprecating methods that have replacements in Joda Time. This would allow us to consider removing them in 3.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-302) StrBuilder does not implement clone()
[ http://issues.apache.org/jira/browse/LANG-302?page=comments#action_12461061 ] Stephen Colebourne commented on LANG-302: - I disagree with this. It was probably an error to be Clonable, but now its there its doing no harm. Removing it breaks binary compatability, and thats a big deal in [lang]. -1 to the change. StrBuilder does not implement clone() - Key: LANG-302 URL: http://issues.apache.org/jira/browse/LANG-302 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Reporter: Henri Yandell Fix For: 2.3 As reported by FindBugs. Does StrBuilder need to be Cloneable? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-282) Create more tests to test out the +=31 replacement code in DurationFormatUtils.
[
http://issues.apache.org/jira/browse/LANG-282?page=comments#action_12456773 ]
Stephen Colebourne commented on LANG-282:
-
In fact, there is a third answer to the question 2 months and -5 days.
Create more tests to test out the +=31 replacement code in
DurationFormatUtils.
---
Key: LANG-282
URL: http://issues.apache.org/jira/browse/LANG-282
Project: Commons Lang
Issue Type: Task
Reporter: Henri Yandell
Assigned To: Henri Yandell
Fix For: 2.3
Code being:
while (days 0) {
end.add(Calendar.MONTH, -1);
days += end.getActualMaximum(Calendar.DAY_OF_MONTH);
//days += 31; // TODO: Need tests to show this is bad and the new code is
good.
// HEN: It's a tricky subject. Jan 15th to March 10th. If I count days-first
it is
// 1 month and 26 days, but if I count month-first then it is 1 month and 23
days.
// Also it's contextual - if asked for no M in the format then I should
probably
// be doing no calculating here.
months -= 1;
end.add(Calendar.MONTH, 1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-99) FileCleaner thread never ends and cause memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=comments#action_12455486 ] Stephen Colebourne commented on IO-99: -- Please review and try the latest code in SVN. FileCleaner thread never ends and cause memory leak in AS - Key: IO-99 URL: http://issues.apache.org/jira/browse/IO-99 Project: Commons IO Issue Type: Bug Affects Versions: 1.2 Environment: JBOssPortal with commons.fileupload Reporter: Vera Mickaël Priority: Critical Fix For: 1.3 Attachments: IO-99.patch FileCleaner opens a thread and no solution is given to the user to end it. So when an application is undeployed in an Application Server, a thread is still alive. The WebApp can't be undeployed and this results in a classloader leak that will cause an OutOfMemoryError. I think the API should be extended so that a user can end the thread. A better way would be to provide a class that cleans everything for commons IO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=all ] Stephen Colebourne closed IO-86. Resolution: Fixed I'm closing this, as I think its done to everyones satisfaction now. Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-3.patch, io-filefinder-start-end.patch, io.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-84) Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams
[ http://issues.apache.org/jira/browse/IO-84?page=comments#action_12455191 ] Stephen Colebourne commented on IO-84: -- I've changed IOUtils.copy to return -1 rather than an exception. The problem was that copy() was used from lots of other places, which didn't care about the number of bytes copied. As such, I reason that the most common use case for copy() is to not care about the number of bytes copied. By returning -1 from the int copy methods, the bug is dealt with (the result is now consistent and javadocced). The copyLarge() method exists for those that want accurate counts. While copy() itself will never fail to copy, as in previous versions - the most backwards compatible option. Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams - Key: IO-84 URL: http://issues.apache.org/jira/browse/IO-84 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2 Environment: All Reporter: Evgenii Philippov Fix For: 1.3 Attachments: io-84-files-larger-than-2gb.patch java int.MAX_VALUE is 2 GB. Classes that handle streams larger than 2 GB will behave incorrectly. For example, see http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?view=markup Method: int copy(InputStream input, OutputStream output). The correct method would be: long copy(InputStream input, OutputStream output). This issue may affect many classes and routines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-99) FileCleaner thread never ends and cause memory leak in AS
[ http://issues.apache.org/jira/browse/IO-99?page=comments#action_12455206
]
Stephen Colebourne commented on IO-99:
--
The simple solution is to add a method exitWhenFinished() that sets a boolean
flag.
The reaper thread then checks the boolean flag to see if it should stop the
thread (once all tracked objects have been dealt with)
{code}
if (exitWhenFinished trackers.isEmpty()) {
return; // terminate thread
}
{/code}
Code can then call FileCleaner.exitWhenFinished() from their servlet destroy
method.
FileCleaner thread never ends and cause memory leak in AS
-
Key: IO-99
URL: http://issues.apache.org/jira/browse/IO-99
Project: Commons IO
Issue Type: Bug
Affects Versions: 1.2
Environment: JBOssPortal with commons.fileupload
Reporter: Vera Mickaël
Priority: Critical
FileCleaner opens a thread and no solution is given to the user to end it. So
when an application is undeployed
in an Application Server, a thread is still alive. The WebApp can't be
undeployed and this results in a classloader
leak that will cause an OutOfMemoryError.
I think the API should be extended so that a user can end the thread. A
better way would be to provide a class that
cleans everything for commons IO.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-296) Add method chaining pattern to StopWatch
[ http://issues.apache.org/jira/browse/LANG-296?page=comments#action_12448211 ] Stephen Colebourne commented on LANG-296: - Changing the return type of methods is binary incompatible. Add method chaining pattern to StopWatch Key: LANG-296 URL: http://issues.apache.org/jira/browse/LANG-296 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.2 Environment: any Reporter: Justin Pitts Priority: Trivial Attachments: MethodChainingPattern Implement the method chaining pattern (similiar to StringBuffer) to mutator methods. This enables the following code: StopWatch s = new StopWatch().start(); System.out.println(s.stop().getTime()); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=all ] Stephen Colebourne updated IO-86: - Attachment: io.patch After some consideration, I would like to add in a little more structure for the external use case of cancellation. Niall, I believe that this actually fits with your original proposal. This patch adds a handleIsCancelled() method, but leaves the implementation up to the subclass. The subclass is still free to ignore this method and do their own thing if they need to, but IMO this method simplifies the cross thread collaboration for most external cancellation use cases. If adopted, a test is needed for this patch. Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-3.patch, io-filefinder-start-end.patch, io.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12447997 ] Stephen Colebourne commented on IO-86: -- I may also need to add the collection of results to the exception. Without it, the code that receives the exception can't see the files that have been processed unless it created the collection itself (which most clients won't do) Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-3.patch, io-filefinder-start-end.patch, io.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-225) Contribution: A Patricia Tree
[ http://issues.apache.org/jira/browse/COLLECTIONS-225?page=comments#action_12447509 ] Stephen Colebourne commented on COLLECTIONS-225: Yep, so long as I can get the project slimmed down in the generics process, there is no reason for it not to take in useful ideas/code again :-) Contribution: A Patricia Tree - Key: COLLECTIONS-225 URL: http://issues.apache.org/jira/browse/COLLECTIONS-225 Project: Commons Collections Issue Type: New Feature Components: Map Reporter: Sam Berlin Attachments: pat.zip We (Roger Kapsi I) would like to contribute a Patricia tree. The tree implements the Map SortedMap interface, meaning it can be used as a replacement for any arbitrary map. It also implementes a new 'Trie' interface, allowing other implementations or other varieties of Tries to be added. The tree is currently written for generics, but that can easily be removed. We have used the tree as the structure backing a route table in a new Kademlia-based DHT, as the structure backing an IP filter (storing IP addresses IP ranges, allowing retrieval/searching in nanoseconds), and have tested it with Strings by storing all of 'hamlet' and comparing it against a TreeSet. The tree is also ready to implement NavigableMap whenever Java 1.6 becomes available. I will attach the files in an update to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-234) Please provide nightly builds of collections_jdk5_branch
[ http://issues.apache.org/jira/browse/COLLECTIONS-234?page=comments#action_12447511 ] Stephen Colebourne commented on COLLECTIONS-234: The code isn't nearly ready yet. I will try and push for an early alpha once its vaguely there. Suggest you use http://collections.sf.net until then. Please provide nightly builds of collections_jdk5_branch Key: COLLECTIONS-234 URL: http://issues.apache.org/jira/browse/COLLECTIONS-234 Project: Commons Collections Issue Type: Wish Affects Versions: Generics Reporter: Stepan Koltsov Please provide nightly builds of collections_jdk5_branch. I'd like to use generified commons-collections right now, and not wait until it will be released. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-228) MultiValueMap put and putAll do not return the correct values
MultiValueMap put and putAll do not return the correct values - Key: COLLECTIONS-228 URL: http://issues.apache.org/jira/browse/COLLECTIONS-228 Project: Commons Collections Issue Type: Bug Components: Map Affects Versions: 3.2 Reporter: Stephen Colebourne Priority: Minor Fix For: 3.3, Generics MultiValueMap put and putAll do not return the correct values. putAll(Object, Collection) should return true if the map is changed. But if the key is new then this behaviour fails. put(Object, Object) should return the added value if the map is changed. But if the key is new then this behaviour fails. This was hidden because the test case referred to MultiHashMap and not MultValueMap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-229) Remove deprecated classes from generics version
Remove deprecated classes from generics version --- Key: COLLECTIONS-229 URL: http://issues.apache.org/jira/browse/COLLECTIONS-229 Project: Commons Collections Issue Type: Task Components: Core, Iterator Reporter: Stephen Colebourne Fix For: Generics The generics version should have no deprecations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (COLLECTIONS-228) MultiValueMap put and putAll do not return the correct values
[ http://issues.apache.org/jira/browse/COLLECTIONS-228?page=all ] Stephen Colebourne closed COLLECTIONS-228. -- Resolution: Fixed Assignee: Stephen Colebourne MultiValueMap put and putAll do not return the correct values - Key: COLLECTIONS-228 URL: http://issues.apache.org/jira/browse/COLLECTIONS-228 Project: Commons Collections Issue Type: Bug Components: Map Affects Versions: 3.2 Reporter: Stephen Colebourne Assigned To: Stephen Colebourne Priority: Minor Fix For: 3.3, Generics MultiValueMap put and putAll do not return the correct values. putAll(Object, Collection) should return true if the map is changed. But if the key is new then this behaviour fails. put(Object, Object) should return the added value if the map is changed. But if the key is new then this behaviour fails. This was hidden because the test case referred to MultiHashMap and not MultValueMap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-229) Remove deprecated classes from generics version
[ http://issues.apache.org/jira/browse/COLLECTIONS-229?page=comments#action_12445372 ] Stephen Colebourne commented on COLLECTIONS-229: Deleted: - org.apache.commons.collections.BeanMap - org.apache.commons.collections.BinaryHeap - org.apache.commons.collections.BoundedFifoBuffer - org.apache.commons.collections.CursorableLinkedList - org.apache.commons.collections.DefaultMapBag - org.apache.commons.collections.DefaultMapEntry - org.apache.commons.collections.DoubleOrderedMap - org.apache.commons.collections.HashBag - org.apache.commons.collections.LRUMap - org.apache.commons.collections.MultiHashMap - org.apache.commons.collections.PriorityQueue - org.apache.commons.collections.ProxyMap - org.apache.commons.collections.ReferenceMap - org.apache.commons.collections.SequencedHashMap - org.apache.commons.collections.StaticBucketMap - org.apache.commons.collections.SynchronizedPriorityQueue - org.apache.commons.collections.TreeBag - org.apache.commons.collections.UnboundedFifoBuffer - org.apache.commons.collections.iterators.ProxyIterator - org.apache.commons.collections.iterators.ProxyListIterator - org.apache.commons.collections.TestBeanMap - org.apache.commons.collections.TestBinaryHeap - org.apache.commons.collections.TestBoundedFifoBuffer - org.apache.commons.collections.TestBoundedFifoBuffer2 - org.apache.commons.collections.TestCursorableLinkedList - org.apache.commons.collections.TestDoubleOrderedMap - org.apache.commons.collections.TestHashBag - org.apache.commons.collections.TestLRUMap - org.apache.commons.collections.TestMultiHashMap - org.apache.commons.collections.TestReferenceMap - org.apache.commons.collections.TestSequencedHashMap - org.apache.commons.collections.TestStaticBucketMap - org.apache.commons.collections.TestTreeBag - org.apache.commons.collections.TestUnboundedFifoBuffer Modified: - org.apache.commons.collections.ExtendedProperties - org.apache.commons.collections.MapPerformance - org.apache.commons.collections.TestAll - org.apache.commons.collections.TestExtendedProperties - org.apache.commons.collections.list.TestCursorableLinkedList Remove deprecated classes from generics version --- Key: COLLECTIONS-229 URL: http://issues.apache.org/jira/browse/COLLECTIONS-229 Project: Commons Collections Issue Type: Task Components: Core, Iterator Reporter: Stephen Colebourne Fix For: Generics The generics version should have no deprecations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-229) Remove deprecated classes from generics version
[ http://issues.apache.org/jira/browse/COLLECTIONS-229?page=comments#action_12445374 ] Stephen Colebourne commented on COLLECTIONS-229: Modified: - org.apache.commons.collections.CollectionUtils - org.apache.commons.collections.AbstractDualBidiMap - org.apache.commons.collections.TestCollectionUtils Remove deprecated classes from generics version --- Key: COLLECTIONS-229 URL: http://issues.apache.org/jira/browse/COLLECTIONS-229 Project: Commons Collections Issue Type: Task Components: Core, Iterator Reporter: Stephen Colebourne Fix For: Generics The generics version should have no deprecations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (COLLECTIONS-218) CollectionUtils.select() does not return passed in collection
[ http://issues.apache.org/jira/browse/COLLECTIONS-218?page=all ] Stephen Colebourne reopened COLLECTIONS-218: Implement for Generics CollectionUtils.select() does not return passed in collection - Key: COLLECTIONS-218 URL: http://issues.apache.org/jira/browse/COLLECTIONS-218 Project: Commons Collections Issue Type: Improvement Components: Core Affects Versions: 3.2 Reporter: Stephen Kestle Assigned To: Stephen Colebourne Fix For: Generics Attachments: CollectionUtils select return.patch collect has the following methods: Collection collect(Collection inputCollection, final Transformer transformer) Collection collect(Collection inputCollection, final Transformer transformer, final Collection outputCollection) The first creates an ArrayList(), where the second takes an outputCollection and, for convenience, returns it. Select (and selectReject) currently the following methods: Collection select(Collection inputCollection, Predicate predicate) void select(Collection inputCollection, Predicate predicate, Collection outputCollection) I propose changing the bottom method to return the passed in outputCollection. It would simplify calling code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-218) CollectionUtils.select() does not return passed in collection
[ http://issues.apache.org/jira/browse/COLLECTIONS-218?page=all ] Stephen Colebourne updated COLLECTIONS-218: --- Fix Version/s: Generics CollectionUtils.select() does not return passed in collection - Key: COLLECTIONS-218 URL: http://issues.apache.org/jira/browse/COLLECTIONS-218 Project: Commons Collections Issue Type: Improvement Components: Core Affects Versions: 3.2 Reporter: Stephen Kestle Assigned To: Stephen Colebourne Fix For: Generics Attachments: CollectionUtils select return.patch collect has the following methods: Collection collect(Collection inputCollection, final Transformer transformer) Collection collect(Collection inputCollection, final Transformer transformer, final Collection outputCollection) The first creates an ArrayList(), where the second takes an outputCollection and, for convenience, returns it. Select (and selectReject) currently the following methods: Collection select(Collection inputCollection, Predicate predicate) void select(Collection inputCollection, Predicate predicate, Collection outputCollection) I propose changing the bottom method to return the passed in outputCollection. It would simplify calling code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (COLLECTIONS-148) [collections] Change to HashEntry inner class of AbstractHashedMap
[ http://issues.apache.org/jira/browse/COLLECTIONS-148?page=all ]
Stephen Colebourne reopened COLLECTIONS-148:
Reconsider this work for Generics version
[collections] Change to HashEntry inner class of AbstractHashedMap
--
Key: COLLECTIONS-148
URL: http://issues.apache.org/jira/browse/COLLECTIONS-148
Project: Commons Collections
Issue Type: Improvement
Environment: Operating System: other
Platform: All
Reporter: Henry Story
Priority: Minor
Fix For: Generics
Attachments: collections-altered.jpg, collections.jpg, hashed.tar,
patch.txt
The way the AbstractHashedMap class is currently written it is not as
extensible as it could be.
The HashEntry static inner class is abstract. By slightly refactoring it to
an inner interface one can get a
lot more mileage out of it.
This change has minimal impact on four other classes from the map package.
Two extra classes which I will submit as a seperate patch (should I do this
before this one is accepted?)
that use this inner interface are a HashedSet and a WeakHashedSet. Both of
these classes are adapters
of a subclass of the changed AbstractHashedMap.
The HashEntry interface essentially hides the representation of the key and
value objects. In a HashSet
the key is the value, so this avoids the duplication - not of objects, but of
references. More importantly
it also allows a HashEntry to extend a WeakReference Object, which cannot be
done as the code
presently stands.
Here is the new interface:
protected static interface HashEntry extends Map.Entry, KeyValue {
public HashEntry getNext();
public void setNext(HashEntry next);
public int getHashCode();
public void setHashCode(int hashCode);
/**
* @param key raw key (ie, no interpretation for special cases like
NULL
*/
public void setRawKey(Object key);
/**
*
* @return the raw key
*/
public Object getRawKey();
}
This allows the implementation to decide how they can refer to the key and
the values. Essentially we
remove all reference in the code to the variables 'key' and 'value' and
replace them with the (set/
get)rawkey (set/get)value methods. The raw key method is necessary as the
setKey method is often
overridden to do special null substition work.
I have also created a more interesting NULL object, that can better describe
itself. When debugging it is
often helpful to know that one is looking at a NULL object.
Finally I also - and debatably wrongly - changed the Iterator from static
inner classes to real inner
classes. This is how it is meant to work anyway. An inner class just has a
reference to its enclosing
class. But perhaps there is something here that I have not understood. My
other contributions don't
hang on this change. They just make the code a little simpler.
If the intention is to extract these classes to an external package, then the
current solution of having a
static inner class makes sense.
I will attach class diagrams and diffs to this request to clarify the changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-148) [collections] Change to HashEntry inner class of AbstractHashedMap
[ http://issues.apache.org/jira/browse/COLLECTIONS-148?page=all ]
Stephen Colebourne updated COLLECTIONS-148:
---
Bugzilla Id: (was: 27231)
Fix Version/s: Generics
[collections] Change to HashEntry inner class of AbstractHashedMap
--
Key: COLLECTIONS-148
URL: http://issues.apache.org/jira/browse/COLLECTIONS-148
Project: Commons Collections
Issue Type: Improvement
Environment: Operating System: other
Platform: All
Reporter: Henry Story
Priority: Minor
Fix For: Generics
Attachments: collections-altered.jpg, collections.jpg, hashed.tar,
patch.txt
The way the AbstractHashedMap class is currently written it is not as
extensible as it could be.
The HashEntry static inner class is abstract. By slightly refactoring it to
an inner interface one can get a
lot more mileage out of it.
This change has minimal impact on four other classes from the map package.
Two extra classes which I will submit as a seperate patch (should I do this
before this one is accepted?)
that use this inner interface are a HashedSet and a WeakHashedSet. Both of
these classes are adapters
of a subclass of the changed AbstractHashedMap.
The HashEntry interface essentially hides the representation of the key and
value objects. In a HashSet
the key is the value, so this avoids the duplication - not of objects, but of
references. More importantly
it also allows a HashEntry to extend a WeakReference Object, which cannot be
done as the code
presently stands.
Here is the new interface:
protected static interface HashEntry extends Map.Entry, KeyValue {
public HashEntry getNext();
public void setNext(HashEntry next);
public int getHashCode();
public void setHashCode(int hashCode);
/**
* @param key raw key (ie, no interpretation for special cases like
NULL
*/
public void setRawKey(Object key);
/**
*
* @return the raw key
*/
public Object getRawKey();
}
This allows the implementation to decide how they can refer to the key and
the values. Essentially we
remove all reference in the code to the variables 'key' and 'value' and
replace them with the (set/
get)rawkey (set/get)value methods. The raw key method is necessary as the
setKey method is often
overridden to do special null substition work.
I have also created a more interesting NULL object, that can better describe
itself. When debugging it is
often helpful to know that one is looking at a NULL object.
Finally I also - and debatably wrongly - changed the Iterator from static
inner classes to real inner
classes. This is how it is meant to work anyway. An inner class just has a
reference to its enclosing
class. But perhaps there is something here that I have not understood. My
other contributions don't
hang on this change. They just make the code a little simpler.
If the intention is to extract these classes to an external package, then the
current solution of having a
static inner class makes sense.
I will attach class diagrams and diffs to this request to clarify the changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (COLLECTIONS-182) [collections] Change CollectionUtils.forAllDo to return the Closure
[ http://issues.apache.org/jira/browse/COLLECTIONS-182?page=all ]
Stephen Colebourne reopened COLLECTIONS-182:
Reconsider for generics version
[collections] Change CollectionUtils.forAllDo to return the Closure
---
Key: COLLECTIONS-182
URL: http://issues.apache.org/jira/browse/COLLECTIONS-182
Project: Commons Collections
Issue Type: Improvement
Affects Versions: 3.1
Environment: Operating System: All
Platform: All
Reporter: Jim Cakalic
Priority: Minor
Fix For: Generics
I frequently use CollectionUtils.forAllDo with a Closure that determines some
kind of aggregate value across the members of the Collection. For example, and
this is entirely manufactured, say I have an Order with a collection of
LineItems. Order might use a SumClosure to count the number of actual items
(not
LineItem objects) on the Order or to compute the sum of the LineItems cost. It
would be convenient in these cases if I could use the return of forAllDo to
chain method calls like this:
public BigDecimal getTotal() {
return CollectionUtils.forAllDo(lineItems, new
SumTotalClosure()).total();
}
As it is, I have to make do with the somewhat less compact:
public BigDecimal getTotal() {
SumTotalClosure closure = new SumTotalClosure();
CollectionUtils.forAllDo(lineItems, closure);
return closure.total();
}
Thanks for considering it.
Regards,
Jim Cakalic
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-182) [collections] Change CollectionUtils.forAllDo to return the Closure
[ http://issues.apache.org/jira/browse/COLLECTIONS-182?page=all ]
Stephen Colebourne updated COLLECTIONS-182:
---
Bugzilla Id: (was: 35955)
Fix Version/s: Generics
[collections] Change CollectionUtils.forAllDo to return the Closure
---
Key: COLLECTIONS-182
URL: http://issues.apache.org/jira/browse/COLLECTIONS-182
Project: Commons Collections
Issue Type: Improvement
Affects Versions: 3.1
Environment: Operating System: All
Platform: All
Reporter: Jim Cakalic
Priority: Minor
Fix For: Generics
I frequently use CollectionUtils.forAllDo with a Closure that determines some
kind of aggregate value across the members of the Collection. For example, and
this is entirely manufactured, say I have an Order with a collection of
LineItems. Order might use a SumClosure to count the number of actual items
(not
LineItem objects) on the Order or to compute the sum of the LineItems cost. It
would be convenient in these cases if I could use the return of forAllDo to
chain method calls like this:
public BigDecimal getTotal() {
return CollectionUtils.forAllDo(lineItems, new
SumTotalClosure()).total();
}
As it is, I have to make do with the somewhat less compact:
public BigDecimal getTotal() {
SumTotalClosure closure = new SumTotalClosure();
CollectionUtils.forAllDo(lineItems, closure);
return closure.total();
}
Thanks for considering it.
Regards,
Jim Cakalic
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-227) TreeBidiMap should implement SortedBidiMap
TreeBidiMap should implement SortedBidiMap -- Key: COLLECTIONS-227 URL: http://issues.apache.org/jira/browse/COLLECTIONS-227 Project: Commons Collections Issue Type: Improvement Components: BidiMap Reporter: Stephen Colebourne Priority: Trivial TreeBidiMap should implement SortedBidiMap as it fulfils the criteria. (Note that at present, the ordering in TreeBidiMap is limited to natural ordering) This issue needs a patch to actually go anywhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-276) MutableBigDecimal and MutableBigInteger
[ http://issues.apache.org/jira/browse/LANG-276?page=comments#action_12444034 ] Stephen Colebourne commented on LANG-276: - Thinking about this, MutableBigInteger is a generified version of MutableObject. So, this should probably be delayed until [lang] has a JDK5+ version. MutableBigDecimal and MutableBigInteger --- Key: LANG-276 URL: http://issues.apache.org/jira/browse/LANG-276 Project: Commons Lang Issue Type: New Feature Reporter: Simon Kitching Priority: Minor Fix For: 3.0 The mutable package covers most of the standard immutable data-types, but not BigDecimal or BigInteger. I actually had a need for a mutable BigDecimal today (money amount out parameter) and noticed the lack. With these two done, that would be all subclasses of java.lang.Number covered... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-282) Create more tests to test out the +=31 replacement code in DurationFormatUtils.
[
http://issues.apache.org/jira/browse/LANG-282?page=comments#action_12444035 ]
Stephen Colebourne commented on LANG-282:
-
As far as Joda-Time is concerned, both answers to the question are right.
Create more tests to test out the +=31 replacement code in
DurationFormatUtils.
---
Key: LANG-282
URL: http://issues.apache.org/jira/browse/LANG-282
Project: Commons Lang
Issue Type: Task
Reporter: Henri Yandell
Assigned To: Henri Yandell
Fix For: 3.0
Code being:
while (days 0) {
end.add(Calendar.MONTH, -1);
days += end.getActualMaximum(Calendar.DAY_OF_MONTH);
//days += 31; // TODO: Need tests to show this is bad and the new code is
good.
// HEN: It's a tricky subject. Jan 15th to March 10th. If I count days-first
it is
// 1 month and 26 days, but if I count month-first then it is 1 month and 23
days.
// Also it's contextual - if asked for no M in the format then I should
probably
// be doing no calculating here.
months -= 1;
end.add(Calendar.MONTH, 1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-288) StrTokenizer needs to support access to the token separators
StrTokenizer needs to support access to the token separators Key: LANG-288 URL: http://issues.apache.org/jira/browse/LANG-288 Project: Commons Lang Issue Type: Improvement Reporter: Stephen Colebourne Priority: Minor Fix For: 3.0 With StrTokenizer at present you cannot extract the separators between the tokens, a feature which is possible with StringTokenizer. Thus tokenizing [EMAIL PROTECTED] using .@ would return a,b,c,d but you wouldn't know where the @ was. This could probably best be part of the API as a lastSeparator() method that can only be called after next(), returning the separator(s) between that token and the previous token. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-285) Wish : method unaccent
[ http://issues.apache.org/jira/browse/LANG-285?page=comments#action_12442273 ] Stephen Colebourne commented on LANG-285: - Sounds interesting. Does the uniode handling in Java provide this info? Perhaps on the Character class. Wish : method unaccent -- Key: LANG-285 URL: http://issues.apache.org/jira/browse/LANG-285 Project: Commons Lang Issue Type: New Feature Reporter: Guillaume Coté Priority: Minor I would like to add a method that replace accented caracter by unaccented one. For example, with the input String L'été où j'ai dû aller à l'île d'Anticosti commenca tôt, the method would return L'ete ou j'ai du aller à l'ile d'Anticosti commenca tot. I suggest to call that method unaccent and to add it in StringUtils. If we cannot covert all case, the first version could only covert iso-8859-1. If you are willing to go forward with that idea, I am willing to contribute a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-94) New NullnputStream NullReader implementations
[ http://issues.apache.org/jira/browse/IO-94?page=all ] Stephen Colebourne closed IO-94. Resolution: Fixed New NullnputStream NullReader implementations --- Key: IO-94 URL: http://issues.apache.org/jira/browse/IO-94 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 Attachments: MockInputStream.java, MockInputStreamTestCase.java I have created a MockInputStream which can be plugged in for testing parts of systems where the data doesn't matter - the main use I've had for it was testing large files - without actually having the InputStream process large amounts of bytes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-82) Test takes a long time to run in Mustang
[ http://issues.apache.org/jira/browse/IO-82?page=comments#action_12441785 ] Stephen Colebourne commented on IO-82: -- We need to force a gc to start the cleaner working Test takes a long time to run in Mustang Key: IO-82 URL: http://issues.apache.org/jira/browse/IO-82 Project: Commons IO Issue Type: Bug Environment: Mustang RC b90 on Linux (x86) http://www.java.net/download/jdk6/binaries/jdk-6-rc-bin-b90-linux-i586-30_jun_2006.bin Reporter: Henri Yandell Fix For: 1.3 [junit] Running org.apache.commons.io.FileCleanerTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 116.485 sec On 1.4.2 on the same machine/checkout, it takes only 1.x seconds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-94) New Mock InputStream Writer implementations
[ http://issues.apache.org/jira/browse/IO-94?page=comments#action_12441851 ] Stephen Colebourne commented on IO-94: -- As I said before, I'm unsure of the use case outside mocking, but this is a strange world, and someone will probably think of one... perhaps in a pipeline of some kind. Certainly, the 'mock' name is inappropriate, and I agree that they are a parallel to the 'null' ones, but the 'null' name may be inappropriate here, not sure. I suggest that we accept them as the parallel to the null inputs. Can you rename them to Null* (unless anyone can think of a better name) add to the release notes. New Mock InputStream Writer implementations - Key: IO-94 URL: http://issues.apache.org/jira/browse/IO-94 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 Attachments: MockInputStream.java, MockInputStreamTestCase.java I have created a MockInputStream which can be plugged in for testing parts of systems where the data doesn't matter - the main use I've had for it was testing large files - without actually having the InputStream process large amounts of bytes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12441855 ] Stephen Colebourne commented on IO-86: -- It sounds like you have a use case for this which I don't have at present. I suggest that you commit your code and we make minor tweaks from there. The aim should be simple internal and external cancellation, well documented. Oh and can we ensure the exception class ends in 'Exception'? BTW, I think that the performance of one volatile boolean relative to an IO operation is going to be absolutely insignificant! Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-3.patch, io-filefinder-start-end.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-82) Test takes a long time to run in Mustang
[ http://issues.apache.org/jira/browse/IO-82?page=comments#action_12441375 ] Stephen Colebourne commented on IO-82: -- I'd like to get IO 1.3 out soon. Hen, can you confirm this issue still exists? Test takes a long time to run in Mustang Key: IO-82 URL: http://issues.apache.org/jira/browse/IO-82 Project: Commons IO Issue Type: Bug Environment: Mustang RC b90 on Linux (x86) http://www.java.net/download/jdk6/binaries/jdk-6-rc-bin-b90-linux-i586-30_jun_2006.bin Reporter: Henri Yandell Fix For: 1.3 [junit] Running org.apache.commons.io.FileCleanerTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 116.485 sec On 1.4.2 on the same machine/checkout, it takes only 1.x seconds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-84) Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams
[ http://issues.apache.org/jira/browse/IO-84?page=comments#action_12441471 ] Stephen Colebourne commented on IO-84: -- I've changed these from deprecated to throw an exception instead (although I'm open to -1/MIN_VALUE/MAX_VALUE too) The reason is that most users will probably only care about smaller files, and inconveniencing the many for the few is too harsh a response to this problem.The javadoc together with an exception would seem to be a safe way to deal with the problem. This call is now awaiting feedback or closure. Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams - Key: IO-84 URL: http://issues.apache.org/jira/browse/IO-84 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2 Environment: All Reporter: Evgenii Philippov Fix For: 1.3 Attachments: io-84-files-larger-than-2gb.patch java int.MAX_VALUE is 2 GB. Classes that handle streams larger than 2 GB will behave incorrectly. For example, see http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?view=markup Method: int copy(InputStream input, OutputStream output). The correct method would be: long copy(InputStream input, OutputStream output). This issue may affect many classes and routines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12441483 ] Stephen Colebourne commented on IO-86: -- Why a boolean? Firstly, because it reduces the jar file size slightly (each class is an overhead), but secondly because I wanted the handlers to be able to ignore the cancellation request (which they can't do with an exception because its too late by that point). What you're suggesting now could almost argue for no cancellation behaviour at all - what does CancelledOperation(Exception) give over throwing an IOException directly? I do agree that the code I checked in doesn't support the internal model of cancellation. This could be fixed by adding a setCancelled() method and a boolean flag. Maybe we are worrying too much about the sync cost of volatile? Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-2.patch, io-filefinder-start-end.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-95) New NullWriter implementation
[ http://issues.apache.org/jira/browse/IO-95?page=all ] Stephen Colebourne resolved IO-95. -- Resolution: Fixed I removed the unecessary throws IOException,and added the test to the package suite New NullWriter implementation - Key: IO-95 URL: http://issues.apache.org/jira/browse/IO-95 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 Add a new NullWriter class - Writer equivalent of NullOutputStream -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (IO-96) Test case misuses read(byte[]) and read(char[])
Test case misuses read(byte[]) and read(char[])
---
Key: IO-96
URL: http://issues.apache.org/jira/browse/IO-96
Project: Commons IO
Issue Type: Bug
Components: Filters, Streams/Writers, Utilities
Affects Versions: 1.2
Environment: GNU classpath
Reporter: Stephen Colebourne
Assigned To: Stephen Colebourne
Priority: Minor
Fix For: 1.3
Message to mailing list from Anthony Green
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg82127.html
-
This support routine from the commons-io project test code assumed that
FileReader.read(byte[]) would always read the entire file. There's no
such guarantee, and some tests were failing on GNU Classpath based VMs
because of this.
Thanks,
AG
--- src/test/org/apache/commons/io/testtools/FileBasedTestCase.java~
2006-07-13 23:44:13.0 -0700
+++ src/test/org/apache/commons/io/testtools/FileBasedTestCase.java
2006-07-13 23:44:20.0 -0700
@@ -167,18 +171,22 @@
throws IOException
{
Reader ir = new java.io.FileReader( file );
-try {
-char[] c1 = new char[ c0.length ];
-int numRead = ir.read( c1 );
-assertTrue( Different number of bytes, numRead == c0.length );
-for( int i = 0;
- i numRead;
- assertTrue( Byte + i + differs ( + c0[ i ] + != +
c1[ i ] + ),
-c0[ i ] == c1[ i ] ), i++
-);
-} finally {
-ir.close();
-}
+ int count = 0, numRead = 0;
+ char[] c1 = new char[ c0.length ];
+ try {
+ while (count c0.length)
+ {
+ numRead = ir.read( c1, count, c0.length);
+ for( int i = count;
+ i count+numRead;
+ assertTrue( Byte + i + differs ( + c0[ i ] + != +
c1[ i ] + ),
+ c0[ i ] == c1[ i ] ), i++
+ );
+ count += numRead;
+ }
+ } finally {
+ ir.close();
+ }
}
protected void checkWrite(OutputStream output) throws Exception {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-96) Test case misuses read(byte[]) and read(char[])
[ http://issues.apache.org/jira/browse/IO-96?page=all ]
Stephen Colebourne resolved IO-96.
--
Resolution: Fixed
Test case misuses read(byte[]) and read(char[])
---
Key: IO-96
URL: http://issues.apache.org/jira/browse/IO-96
Project: Commons IO
Issue Type: Bug
Components: Filters, Streams/Writers, Utilities
Affects Versions: 1.2
Environment: GNU classpath
Reporter: Stephen Colebourne
Assigned To: Stephen Colebourne
Priority: Minor
Fix For: 1.3
Message to mailing list from Anthony Green
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg82127.html
-
This support routine from the commons-io project test code assumed that
FileReader.read(byte[]) would always read the entire file. There's no
such guarantee, and some tests were failing on GNU Classpath based VMs
because of this.
Thanks,
AG
--- src/test/org/apache/commons/io/testtools/FileBasedTestCase.java~
2006-07-13 23:44:13.0 -0700
+++ src/test/org/apache/commons/io/testtools/FileBasedTestCase.java
2006-07-13 23:44:20.0 -0700
@@ -167,18 +171,22 @@
throws IOException
{
Reader ir = new java.io.FileReader( file );
-try {
-char[] c1 = new char[ c0.length ];
-int numRead = ir.read( c1 );
-assertTrue( Different number of bytes, numRead == c0.length );
-for( int i = 0;
- i numRead;
- assertTrue( Byte + i + differs ( + c0[ i ] + != +
c1[ i ] + ),
-c0[ i ] == c1[ i ] ), i++
-);
-} finally {
-ir.close();
-}
+ int count = 0, numRead = 0;
+ char[] c1 = new char[ c0.length ];
+ try {
+ while (count c0.length)
+ {
+ numRead = ir.read( c1, count, c0.length);
+ for( int i = count;
+i count+numRead;
+assertTrue( Byte + i + differs ( + c0[ i ] + != +
c1[ i ] + ),
+c0[ i ] == c1[ i ] ), i++
+);
+ count += numRead;
+ }
+ } finally {
+ ir.close();
+ }
}
protected void checkWrite(OutputStream output) throws Exception {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-94) New Mock InputStream Writer implementations
[ http://issues.apache.org/jira/browse/IO-94?page=comments#action_12441493 ] Stephen Colebourne commented on IO-94: -- This feels almost out of scope for [io], which I've always felt was for runtime io work. Is there a use case that isn't as a mock object? Is so, then we can rename it, but adding a 'mock' class to a non-mock jar feels wrong. If it stays, it needs to go in the release notes. New Mock InputStream Writer implementations - Key: IO-94 URL: http://issues.apache.org/jira/browse/IO-94 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 Attachments: MockInputStream.java, MockInputStreamTestCase.java I have created a MockInputStream which can be plugged in for testing parts of systems where the data doesn't matter - the main use I've had for it was testing large files - without actually having the InputStream process large amounts of bytes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-82) Test takes a long time to run in Mustang
[ http://issues.apache.org/jira/browse/IO-82?page=comments#action_12441496
]
Stephen Colebourne commented on IO-82:
--
This looks a mite dodgy:
while (FileCleaner.getTrackCount() != 0) {
System.gc();
}
JDK1.6 could have altered System.gc to not do anything, thus it takes longer.
Try adding this
int total = 0;
while (FileCleaner.getTrackCount() != 0) {
byte[] b = new byte[1024 * 1024];
b[0] = (byte) System.currentTimeMillis();
total = total + b[0];
System.gc();
}
to waste some memory and kick the gc (I know its just as bad...)
Test takes a long time to run in Mustang
Key: IO-82
URL: http://issues.apache.org/jira/browse/IO-82
Project: Commons IO
Issue Type: Bug
Environment: Mustang RC b90 on Linux (x86)
http://www.java.net/download/jdk6/binaries/jdk-6-rc-bin-b90-linux-i586-30_jun_2006.bin
Reporter: Henri Yandell
Fix For: 1.3
[junit] Running org.apache.commons.io.FileCleanerTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 116.485 sec
On 1.4.2 on the same machine/checkout, it takes only 1.x seconds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-46) [io] Find file in classpath
[ http://issues.apache.org/jira/browse/IO-46?page=all ]
Stephen Colebourne updated IO-46:
-
Bugzilla Id: (was: 38523)
Fix Version/s: 1.4
(was: 1.3)
Moving to 1.4 as there are issues with different classloaders. Also URL formats
can get weird in app servers. This needs quite a bit of thought.
[io] Find file in classpath
---
Key: IO-46
URL: http://issues.apache.org/jira/browse/IO-46
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.1
Environment: Operating System: other
Platform: Other
Reporter: David Leal
Priority: Minor
Fix For: 1.4
Just to suggest adding a method like this:
public File findFileInClasspath(String fileName) throws
FileNotFoundException
{
URL url = getClass().getClassLoader().getResource(fileName);
if (url == null){
throw new FileNotFoundException(fileName);
}
return new File(url.getFile());
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12441499
]
Stephen Colebourne commented on IO-89:
--
Where are we with this? Have you got a finalised proposal? Certainly bug
squashing and javadoc fixes are good.
Inconsistency in SizeFileFilter and AgeFileFilter implementations
-
Key: IO-89
URL: http://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: 1.3
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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12441574
]
Stephen Colebourne commented on IO-89:
--
I can see a javadoc fix as being valid here, but I don't believe we can change
= to . I also wonder how often the full variety of operators is needed.
I'm happy if you want to propose out a complete and more advanced solution with
all the operators, but for now, I think we should just javadoc this (including
the method params if possible).
Inconsistency in SizeFileFilter and AgeFileFilter implementations
-
Key: IO-89
URL: http://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: 1.3
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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-84) Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams
[ http://issues.apache.org/jira/browse/IO-84?page=comments#action_12441575 ] Stephen Colebourne commented on IO-84: -- I'm happy with these IOUtils additions, so feel free to commit if you get a chance. Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams - Key: IO-84 URL: http://issues.apache.org/jira/browse/IO-84 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2 Environment: All Reporter: Evgenii Philippov Fix For: 1.3 Attachments: io-84-files-larger-than-2gb.patch java int.MAX_VALUE is 2 GB. Classes that handle streams larger than 2 GB will behave incorrectly. For example, see http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?view=markup Method: int copy(InputStream input, OutputStream output). The correct method would be: long copy(InputStream input, OutputStream output). This issue may affect many classes and routines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12441581 ] Stephen Colebourne commented on IO-86: -- This is beginning to feel like a can of worms. With the exception/handleCancelled combination, why do we need handleCancelled? We are asking the user to write all the logic to determmine cancellation and handle it by throwing the exception, so why not handle the cancellation fully at that point? Is there enough benefit to justify the combination? Also, I think that there may be a hidden danger/issue. A user writing a public cancel method to be called in another thread may just throw CancellationException and expect the operation to end, which of course it won't. Instead, they have to write all the boolean handling logic to trap in the directory and file levels of the looping. My point here is that while an exception is probably the right design choice in a single-threaded world for this problem, it doesn't strike me as such in a muti-threaded world. Perhaps this can be javadoced so users only throw CancellationException from the right thread, but it surely makes the class riskier. You are correct though in saying that it would allow more data to be transferred to handleCancelled(). This can be worked around using instance variables in the subclass, or handling at the point of identifying the problem. At this point, we hit a problem of not having real-life users yet. So, my preferred solution is to add the boolean cancelled field to DirectoryWalker together with a setCancelled(boolean) method. This means a full cancel solution is provided (which is a nice value add for the class), and documented, but doesn't prevent a subclass using an exception to achieve the same effect if it desires. Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-3.patch, io-filefinder-start-end.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-93) FileSystemUtils needs to call Process.destroy() on exec'd processes
[ http://issues.apache.org/jira/browse/IO-93?page=all ] Stephen Colebourne resolved IO-93. -- Resolution: Fixed Was more complicated than I expeted. I have coded a solution, however it really seems that Process in the JDK is basically rubbish. Anyway, I've improved what we have, rather than go to a full blown commons-exec solution. I can't test or reproduce you're problem on my Windows box. Since you have a test case, can you please try the latest code and reply back (by closing or reopening the call) as to whether the problem is fixed. Thanks. FileSystemUtils needs to call Process.destroy() on exec'd processes --- Key: IO-93 URL: http://issues.apache.org/jira/browse/IO-93 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2 Environment: Java 1.5_06 VM, Red Hat Enterprise Linux 4.0 OS Reporter: Jon Neely Fix For: 1.3 Calling the FileSystemUtils.getFreeSpace() method multiple times (~3000) will generate an IOException with the following text: Too many open files. Documentation from Sun says this problem is due to not destroying the java.lang.Process object returned from the System.exec() call. Some sample code I wrote confirms that calling destroy prevents this error from occurring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-84) Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams
[ http://issues.apache.org/jira/browse/IO-84?page=comments#action_12440661 ] Stephen Colebourne commented on IO-84: -- This issue only affects IOUtils.copy(InputStream,OutputStream) IOUtils.copy(Reader, Writer) Comment added to these methods Many classes are limited to length of stream 2 GB, and behave incorrectly on larger streams - Key: IO-84 URL: http://issues.apache.org/jira/browse/IO-84 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2 Environment: All Reporter: Evgenii Philippov Fix For: 1.3 java int.MAX_VALUE is 2 GB. Classes that handle streams larger than 2 GB will behave incorrectly. For example, see http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/IOUtils.java?view=markup Method: int copy(InputStream input, OutputStream output). The correct method would be: long copy(InputStream input, OutputStream output). This issue may affect many classes and routines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-56) [io] FileCleaner - delete non empty directories
[ http://issues.apache.org/jira/browse/IO-56?page=all ] Stephen Colebourne closed IO-56. Resolution: Fixed No feedback, so closing as complete in rv439102 for v1.3 [io] FileCleaner - delete non empty directories --- Key: IO-56 URL: http://issues.apache.org/jira/browse/IO-56 Project: Commons IO Issue Type: Improvement Components: Utilities Environment: Operating System: Linux Platform: PC Reporter: Kazimierz Pogoda Priority: Minor Fix For: 1.3 It is a feature request. FileCleaner is using java.io.File#delete() method in the inner class Tracker. I suggest to use FileUtils#forceDelete(File) method. This way also non-empty directories can be deleted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=all ] Stephen Colebourne updated IO-86: - Component/s: Utilities Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-2.patch, io-filefinder-start-end.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-70) [io] Add a secureDelete method to FileUtils.java
[ http://issues.apache.org/jira/browse/IO-70?page=all ] Stephen Colebourne closed IO-70. Resolution: Fixed No feedback so losing as fixed in rv439102 for v1.3. [io] Add a secureDelete method to FileUtils.java Key: IO-70 URL: http://issues.apache.org/jira/browse/IO-70 Project: Commons IO Issue Type: Improvement Components: Utilities Environment: Operating System: other Platform: All Reporter: Ralf Hauser Priority: Minor Fix For: 1.3 in org.apache.commons.io.FileUtils Commons Fileupload uses at least the io's FileCleaner.track() method. Unfortunately, they just use the plain java File.delete() method and not a more sophisticated delete as offered in this package. Especially, if servers running the FileUpload are sitting in DMZs and forward all personal/private uploaded information in another (DB-)server behind another firewall, one would not want that if the DMZ machine gets hacked, all previous uploads that are supposedly deleted still can easily be found on the disk by a not even that skilled attacker. Therefore, it would be great to have a pgp-wipe alike secure delete method here! it would overwrite the file multiple times and probably, it this should be spawned as a separte thread since that may take longer than a state-of-the-art GUI would want to wait for such an action to complete. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-92) Add DeferredPeriodicOutputStream
[ http://issues.apache.org/jira/browse/IO-92?page=all ] Stephen Colebourne updated IO-92: - Summary: Add DeferredPeriodicOutputStream (was: new ThresholdingOutputStream implementation) Issue Type: New Feature (was: Improvement) Fix Version/s: 1.4 Affects Version/s: (was: 1.2) Add DeferredPeriodicOutputStream Key: IO-92 URL: http://issues.apache.org/jira/browse/IO-92 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Environment: Windows XP SP2, jdk 1.5 Reporter: Michele Mazzucco Fix For: 1.4 Attachments: DeferredPeriodicOutputStream.java, DeferredPeriodicOutputStreamTest.java I've extended the ThresholdingOutputStream class with a new class which behaves different from DeferredFileOutputStream: - when the stream is closed, the content stored in memory is *always* flushed to disk (in DeferredFileOutputStream, instead, if the treshold is not reached data is lost) - DeferredFileOutputStream maintains data in memory only until the treshold value has been reached, then it immediately writes every byte to disk. This new implementation, instead, caches treshold bytes in memory, and every time that value is reached (that is, treshold, 2 * threshold, etc), it flushes data to disk. In other words it acts as a cache. - It implements the java.io.DataOutput interface, that is, it provides utility methods to write all primitive types (e.g. short, byte, char, int, float, long, double and String in different formats) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12440679 ] Stephen Colebourne commented on IO-86: -- I've comitted a change for cancellation based on this patch but without the exception. I used a boolean instead. It also allows cancellation to be ignored if required. Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-2.patch, io-filefinder-start-end.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12440680 ] Stephen Colebourne commented on IO-86: -- Next question. What about exceptions, notably IOException, which is a checked exception. Should DirectoryWalker - allow each method to throw IOException - handle them - leave it up to subclasses to catch them in each individual method. Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-DirectoryWalker-cancellation-2.patch, io-filefinder-start-end.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-226) ListOrderedMap additional methods
ListOrderedMap additional methods - Key: COLLECTIONS-226 URL: http://issues.apache.org/jira/browse/COLLECTIONS-226 Project: Commons Collections Issue Type: Improvement Components: Map Reporter: Stephen Colebourne Priority: Minor Fix For: 3.3 Some new methods I had a need for on ListOrderedMap: - putAll(int, Map) - set(int, Object key, Object value) - sorting - potentially by making the keyList/valueList/entryList modifiable -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-93) FileSystemUtils needs to call Process.destroy() on exec'd processes
[ http://issues.apache.org/jira/browse/IO-93?page=all ] Stephen Colebourne updated IO-93: - Fix Version/s: 1.3 Definite fix for 1.3 FileSystemUtils needs to call Process.destroy() on exec'd processes --- Key: IO-93 URL: http://issues.apache.org/jira/browse/IO-93 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2 Environment: Java 1.5_06 VM, Red Hat Enterprise Linux 4.0 OS Reporter: Jon Neely Fix For: 1.3 Calling the FileSystemUtils.getFreeSpace() method multiple times (~3000) will generate an IOException with the following text: Too many open files. Documentation from Sun says this problem is due to not destroying the java.lang.Process object returned from the System.exec() call. Some sample code I wrote confirms that calling destroy prevents this error from occurring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-68) [dbcp] Commons Collection dependency version clash when using Commons DBCP via Maven2
[ http://issues.apache.org/jira/browse/DBCP-68?page=comments#action_12435302 ] Stephen Colebourne commented on DBCP-68: Upgrading to a later version of collections shouldn't prove to be a problem. But, I agree with the proposed solution of removng the dependency in this case. Just ensure that neither class being copied is in the public API at the moment, or in the future. [dbcp] Commons Collection dependency version clash when using Commons DBCP via Maven2 - Key: DBCP-68 URL: http://issues.apache.org/jira/browse/DBCP-68 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2 Final Environment: Operating System: All Platform: All Reporter: Christoph Cenowa Fix For: 1.2.2 When using Maven2 to incorporate Commons DBCP 1.2.1 into your project a transient dependency on Commons Collections 2.1 is added. This will clash with other Commons Components like Commons Configuration 1.2 for example that depend on Commons Collections 3.1. Upon adding Commons DBCP 1.2.1 to your project the existing transient dependency on Commons Collections 3.1 gets changed into Commons Collections 2.1. This will result in runtime errors like the following: java.lang.NoClassDefFoundError: org/apache/commons/collections/map/LinkedMap at org.apache.commons.configuration.BaseConfiguration.init(BaseConfiguration.java:53) Since Commons Collections is incorporated into most Commons Components please update the dependency within Commons DBCP to Commons Collections 3.1 if possible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-17) [io] delete in FileUtils sometimes fails on Windows
[ http://issues.apache.org/jira/browse/IO-17?page=all ] Stephen Colebourne closed IO-17. Fix Version/s: (was: 1.3) Resolution: Won't Fix The general agreement here is that this is a bad idea. Also, I can find no Sun bug database report logging this issue (although there are various related misconceptions). Thus, I'm closing as WontFix. Please reopen if there is a Sun bug database report, or a reproducible test case can be created. [io] delete in FileUtils sometimes fails on Windows --- Key: IO-17 URL: http://issues.apache.org/jira/browse/IO-17 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.0 Environment: Operating System: Windows XP Platform: PC Reporter: Wim Deblauwe The delete function in the FileUtils class will sometimes not delete a file or directory on windows. This is a known bug in the VM. Ant solves this by calling the GC explecitly and then wait some time. See http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs/Delete.java?view=markup on how they do it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=all ] Stephen Colebourne updated IO-86: - Summary: Add DirectoryWalker based on FileFinder (was: Add FileFinder back into Commons IO) Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-filefinder-start-end.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add DirectoryWalker based on FileFinder
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12435308 ] Stephen Colebourne commented on IO-86: -- Should we have cancel() functionality in DirectoryWalker? This could be achieved by having a volatile boolean cancel flag and a cancel method. However there would be a performance penalty for systems that don't need this (volatile is a part sync). We could leave cancel out of DirecoryWalker, as its easy to add to subclasses - check the cancel flag at the start of handleFile and in handleDirectory. I think I'd prefer this to be a subclasses responsibility. Add DirectoryWalker based on FileFinder --- Key: IO-86 URL: http://issues.apache.org/jira/browse/IO-86 Project: Commons IO Issue Type: New Feature Affects Versions: 1.2 Reporter: Niall Pemberton Fix For: 1.3 Attachments: FileFinder.java, FileFinderTestCase.java, io-filefinder-start-end.patch I'd like to propose adding a FileFinder back into Commons IO. This is a simplified version of what was recently moved out of Commons IO into the finder component currently in the sandbox. I believe this is a simpler, more generic implementation than the finder component and therefore would be considered suitable for inclusion in Commons IO. Although simpler it could be used as the basis for achieving the finder component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
