[jira] Commented: (NET-187) TFTP Server for commons net
[ https://issues.apache.org/jira/browse/NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576302#action_12576302 ] Niall Pemberton commented on NET-187: - Logically you're right and seeing a rash of server implementations here would not be a good idea. But I don't think thats whats going on here or likely to happen - one trivial impl. thats useful for people to test and IMO *violate* is too strong a word to characterize whats being proposed. Sitting from my armchair IMO Dan has made a good case for adding this one impl. here and just because we accept that doesn't mean we can't say hey stop, lets not do this when someone proposes a second. Precedent has some weight to a certain point, but this is not the legal system and the PMC can make whatever decisions it likes - including preventing further implementations despite accepting this one. TFTP Server for commons net Key: NET-187 URL: https://issues.apache.org/jira/browse/NET-187 Project: Commons Net Issue Type: New Feature Affects Versions: 1.4 Reporter: Dan Armbrust Priority: Minor Fix For: 2.0 Attachments: TFTPServer and Tests.patch Bug for attaching TFTP Server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (BEANUTILS-308) Cannot instantiate BeanUtilsBean class
[ https://issues.apache.org/jira/browse/BEANUTILS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened BEANUTILS-308: --- Cannot instantiate BeanUtilsBean class -- Key: BEANUTILS-308 URL: https://issues.apache.org/jira/browse/BEANUTILS-308 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.8.0-BETA Environment: OP: Windows 2000 Professional Software Plataform: SDK Java 1.5.0_06_b05 + IDE Eclipse 3.3.1.1 Reporter: Marcelo Ingarano Fix For: LATER THAN 1.8.0 I cannot instantiate BeanUtilsBean class with the singleton method getInstance() neither with new clause em Java. Stack Description: Caused by: java.lang.NoSuchMethodError: org.apache.commons.beanutils.converters.StringConverter.init(Ljava/lang/Object;)V at org.apache.commons.beanutils.ConvertUtilsBean.registerStandard(ConvertUtilsBean.java:680) at org.apache.commons.beanutils.ConvertUtilsBean.deregister(ConvertUtilsBean.java:578) at org.apache.commons.beanutils.ConvertUtilsBean.init(ConvertUtilsBean.java:164) at org.apache.commons.beanutils.BeanUtilsBean.init(BeanUtilsBean.java:117) at org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68) at org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153) at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-308) Cannot instantiate BeanUtilsBean class
[ https://issues.apache.org/jira/browse/BEANUTILS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-308. --- Resolution: Invalid OK np, thanks for feeding back Cannot instantiate BeanUtilsBean class -- Key: BEANUTILS-308 URL: https://issues.apache.org/jira/browse/BEANUTILS-308 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.8.0-BETA Environment: OP: Windows 2000 Professional Software Plataform: SDK Java 1.5.0_06_b05 + IDE Eclipse 3.3.1.1 Reporter: Marcelo Ingarano Fix For: LATER THAN 1.8.0 I cannot instantiate BeanUtilsBean class with the singleton method getInstance() neither with new clause em Java. Stack Description: Caused by: java.lang.NoSuchMethodError: org.apache.commons.beanutils.converters.StringConverter.init(Ljava/lang/Object;)V at org.apache.commons.beanutils.ConvertUtilsBean.registerStandard(ConvertUtilsBean.java:680) at org.apache.commons.beanutils.ConvertUtilsBean.deregister(ConvertUtilsBean.java:578) at org.apache.commons.beanutils.ConvertUtilsBean.init(ConvertUtilsBean.java:164) at org.apache.commons.beanutils.BeanUtilsBean.init(BeanUtilsBean.java:117) at org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68) at org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153) at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VALIDATOR-251) url with brackets is not validated thru URLvalidator class.
[
https://issues.apache.org/jira/browse/VALIDATOR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575760#action_12575760
]
Niall Pemberton commented on VALIDATOR-251:
---
Validator 1.4 will run on JDK 1.4
url with brackets is not validated thru URLvalidator class.
---
Key: VALIDATOR-251
URL: https://issues.apache.org/jira/browse/VALIDATOR-251
Project: Commons Validator
Issue Type: Wish
Components: Routines
Affects Versions: 1.3.1 Release
Environment: Java 1.4
Reporter: Meenal Gupta
Fix For: 1.4
Please let me know when VALIDATOR-218, Committed revision 590915 is gng on
release.
As the Below issue is already solved in the bug is VALIDATOR-218.
I cannot find this bus fix in Relaese not for the latest version of commons
jar.
This is very critical for the my application currrent release.
URLvalidator isValid() returns false for validation of urls's which have
brackets ( , ) as one of the content.
url with brackets in them are valid urls , as brackets () are part of the
unreserved characters.
We are using the URLValidator isValid() method to validate Urls.
if (urlValidator.isValid(url)) {
return true;
}
But one of the url is with brackets are rejected by this method.
i am using 1.3.1 version.
Is there something in latest version which already have have fix to this bug.
or my understanding is not correct
Please clarify.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-251) url with brackets is not validated thru URLvalidator class.
[
https://issues.apache.org/jira/browse/VALIDATOR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved VALIDATOR-251.
---
Resolution: Duplicate
url with brackets is not validated thru URLvalidator class.
---
Key: VALIDATOR-251
URL: https://issues.apache.org/jira/browse/VALIDATOR-251
Project: Commons Validator
Issue Type: Wish
Components: Routines
Affects Versions: 1.3.1 Release
Environment: Java 1.4
Reporter: Meenal Gupta
Fix For: 1.4
Please let me know when VALIDATOR-218, Committed revision 590915 is gng on
release.
As the Below issue is already solved in the bug is VALIDATOR-218.
I cannot find this bus fix in Relaese not for the latest version of commons
jar.
This is very critical for the my application currrent release.
URLvalidator isValid() returns false for validation of urls's which have
brackets ( , ) as one of the content.
url with brackets in them are valid urls , as brackets () are part of the
unreserved characters.
We are using the URLValidator isValid() method to validate Urls.
if (urlValidator.isValid(url)) {
return true;
}
But one of the url is with brackets are rejected by this method.
i am using 1.3.1 version.
Is there something in latest version which already have have fix to this bug.
or my understanding is not correct
Please clarify.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-140) IO 2.0 - Move to JDK 1.5
[ https://issues.apache.org/jira/browse/IO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575858#action_12575858 ] Niall Pemberton commented on IO-140: There was talk, but no concrete proposal/patches put forward IO 2.0 - Move to JDK 1.5 Key: IO-140 URL: https://issues.apache.org/jira/browse/IO-140 Project: Commons IO Issue Type: Wish Reporter: Niall Pemberton Fix For: 2.0 Attachments: IO-2.0-deprecate-and-jdk5.patch I just created IO-139 for a StringBuilder Writer implementation that requies JDK 1.5. So I thought I would look at the impact on IO of 1) Removing all deprecations and 2) Making appropriate JDK 1.5 changes (generics, using StringBuilder and new Appendable for Writers). Below is a summary, thought it could be a starting point for discussion about IO 2.0 1) DEPRECATIONS - CopyUtils - FileCleaner - WildcardFilter - FileSystemUtils freeSpace(String) - IOUtils toByteArray(String), toString(byte[]), toString(byte[], String) 2) JDK 1.5 - ConditionalFileFilter List (and also AndFileFilter and OrFileFilter implementations - getFileFilters() and setFileFilters() use generic ListIOFileFilter - Constructor for NameFileFilter, PrefixFileFilter, SuffixFileFilter, WildcardFileFilter use generic ListString - replace StringBuffer with StringBuilder where appropriate (FilenameUtils, FileSystemUtils, HexDump,IOUtils - FileUtils - convertFileCollectionToFileArray() -- CollectionFile - listFiles() -- CollectionFile - listFiles() -- CollectionFile - writeStringToFile String--CharSequence (JDK 1.4+) - ProxyReader - add read(CharBuffer) - IOUtils - readLines(Reader) return ListString - toInputStream(String) -- toInputStream(CharSequence) (JDK 1.4+) - write(String data, OutputStream) and write(StringBuffer data, OutputStream) -- write(CharSequence data, OutputStream) - write(String, Writer) and write(StringBuffer, Writer) -- write(CharSequence data, Writer) - LineIterator Iterator -- IteratorString - NullWriter - add Appendable methods - ProxyWriter - add Appendable methods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-140) IO 2.0 - Move to JDK 1.5
[ https://issues.apache.org/jira/browse/IO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575979#action_12575979 ] Niall Pemberton commented on IO-140: Hmm, for generic types I was guided by eclipse's warnings, but I only had WARN set for Unchecked generic type operation and not Usage of raw type as well - these are now fixed: http://svn.apache.org/viewvc?view=revrevision=634474 thanks Niall IO 2.0 - Move to JDK 1.5 Key: IO-140 URL: https://issues.apache.org/jira/browse/IO-140 Project: Commons IO Issue Type: Wish Reporter: Niall Pemberton Fix For: 2.0 Attachments: IO-2.0-deprecate-and-jdk5.patch I just created IO-139 for a StringBuilder Writer implementation that requies JDK 1.5. So I thought I would look at the impact on IO of 1) Removing all deprecations and 2) Making appropriate JDK 1.5 changes (generics, using StringBuilder and new Appendable for Writers). Below is a summary, thought it could be a starting point for discussion about IO 2.0 1) DEPRECATIONS - CopyUtils - FileCleaner - WildcardFilter - FileSystemUtils freeSpace(String) - IOUtils toByteArray(String), toString(byte[]), toString(byte[], String) 2) JDK 1.5 - ConditionalFileFilter List (and also AndFileFilter and OrFileFilter implementations - getFileFilters() and setFileFilters() use generic ListIOFileFilter - Constructor for NameFileFilter, PrefixFileFilter, SuffixFileFilter, WildcardFileFilter use generic ListString - replace StringBuffer with StringBuilder where appropriate (FilenameUtils, FileSystemUtils, HexDump,IOUtils - FileUtils - convertFileCollectionToFileArray() -- CollectionFile - listFiles() -- CollectionFile - listFiles() -- CollectionFile - writeStringToFile String--CharSequence (JDK 1.4+) - ProxyReader - add read(CharBuffer) - IOUtils - readLines(Reader) return ListString - toInputStream(String) -- toInputStream(CharSequence) (JDK 1.4+) - write(String data, OutputStream) and write(StringBuffer data, OutputStream) -- write(CharSequence data, OutputStream) - write(String, Writer) and write(StringBuffer, Writer) -- write(CharSequence data, Writer) - LineIterator Iterator -- IteratorString - NullWriter - add Appendable methods - ProxyWriter - add Appendable methods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-309) Passing a null argument to ConstructorUtils.invokeConstructor causes NullPointerException
[
https://issues.apache.org/jira/browse/BEANUTILS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575318#action_12575318
]
Niall Pemberton commented on BEANUTILS-309:
---
The problem is it uses the type (class) of the parameters to find the
appropriate constructor to invoke - so for example if you had something like
the following
public class Foo {
public Foo(String param) {
}
public Foo(Integer param) {
}
}
And called
ConstructorUtils.invokeConstructor(Foo.class, new Object[] {null});
Which constructor should it use? I guess it could just pick one arbitarily, but
it might still cause problems.
It will probably be a while before I get round to looking at this, but if you
provide a patch with test cases then it will move up on my list
Passing a null argument to ConstructorUtils.invokeConstructor causes
NullPointerException
-
Key: BEANUTILS-309
URL: https://issues.apache.org/jira/browse/BEANUTILS-309
Project: Commons BeanUtils
Issue Type: Bug
Affects Versions: 1.7.0, 1.8.0-BETA
Reporter: Xavier Poinsard
I am invoking ConstructorUtils.invokeConstructor with an array of arguments
and one of these arguments is null.
This causes a NullPointerException line 120 in Class ConstructorUtils.
Since its not forbidden to pass null argument to a constructor,
ConstructorUtils should handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-309) Passing a null argument to ConstructorUtils.invokeConstructor causes NullPointerException
[
https://issues.apache.org/jira/browse/BEANUTILS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575319#action_12575319
]
Niall Pemberton commented on BEANUTILS-309:
---
btw there is also the following invokeConstructor() method:
public static Object invokeConstructor(Class, Object[], Class[])
..where you can specify the parameter types and avoid this issue. So in the
example I gave above you would do the following to invoked the String
constructor with a null argument:
ConstructorUtils.invokeConstructor(Foo.class, new Object[] {null}, new Class[]
{String.class});
Passing a null argument to ConstructorUtils.invokeConstructor causes
NullPointerException
-
Key: BEANUTILS-309
URL: https://issues.apache.org/jira/browse/BEANUTILS-309
Project: Commons BeanUtils
Issue Type: Bug
Affects Versions: 1.7.0, 1.8.0-BETA
Reporter: Xavier Poinsard
I am invoking ConstructorUtils.invokeConstructor with an array of arguments
and one of these arguments is null.
This causes a NullPointerException line 120 in Class ConstructorUtils.
Since its not forbidden to pass null argument to a constructor,
ConstructorUtils should handle it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575128#action_12575128 ] Niall Pemberton commented on LANG-362: -- Please don't remove the test cases - they may save some effort in the future if this gets implemented Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, ExtendedMessageFormatTest.java, FormatFactory.java Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-308) Cannot instantiate BeanUtilsBean class
[ https://issues.apache.org/jira/browse/BEANUTILS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575176#action_12575176 ] Niall Pemberton commented on BEANUTILS-308: --- Looks like this is a problem in your environment with having an older copy of BeanUtils in your classpath. Before BeanUtils 1.8.0-BETA StringConverter implementation had the default no-args constructor (by omission), but the 1.8.0-BETA introduced an additional StringConverter(Object) constructor which this stack trace indicates it can't find. Cannot instantiate BeanUtilsBean class -- Key: BEANUTILS-308 URL: https://issues.apache.org/jira/browse/BEANUTILS-308 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.8.0-BETA Environment: OP: Windows 2000 Professional Software Plataform: SDK Java 1.5.0_06_b05 + IDE Eclipse 3.3.1.1 Reporter: Marcelo Ingarano I cannot instantiate BeanUtilsBean class with the singleton method getInstance() neither with new clause em Java. Stack Description: Caused by: java.lang.NoSuchMethodError: org.apache.commons.beanutils.converters.StringConverter.init(Ljava/lang/Object;)V at org.apache.commons.beanutils.ConvertUtilsBean.registerStandard(ConvertUtilsBean.java:680) at org.apache.commons.beanutils.ConvertUtilsBean.deregister(ConvertUtilsBean.java:578) at org.apache.commons.beanutils.ConvertUtilsBean.init(ConvertUtilsBean.java:164) at org.apache.commons.beanutils.BeanUtilsBean.init(BeanUtilsBean.java:117) at org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68) at org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153) at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574469#action_12574469 ] Niall Pemberton commented on LANG-362: -- I'm happy with the public API were now exposing to the users and while I haven't looked in detail at the code, it is greatly simplified (thanks Matt!) and writing a test case for it gives me confidence that it works pretty well. So the only outstanding issue is wether we want to suport custom Format implementations in sub-formats (i.e. choice) or just document that they are not supported. I'm happy either way so I would say if Matt has the time and inclination to do it soon then great - otherwise lets just document they are not currently supported (in the ExtendedMessageFormat javadocs) and leave if for a later release. Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, ExtendedMessageFormatTest.java, FormatFactory.java Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-402) OSGi-ify Lang
[ https://issues.apache.org/jira/browse/LANG-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-402. -- Resolution: Fixed The maven-build-plugin is now in commons-parent 8 and lang has been configured and updated to use that version - so this now resolved for m2 http://svn.apache.org/viewvc/commons/proper/lang/trunk/pom.xml?r1=612787r2=632815 OSGi-ify Lang - Key: LANG-402 URL: https://issues.apache.org/jira/browse/LANG-402 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Assignee: Niall Pemberton Fix For: 2.4 Attachments: LANG-402-OSGi-jar-maniest.patch Pre-release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-307) BeanUtils.setProperty(...) not working for property xValue (see description for reason)
[ https://issues.apache.org/jira/browse/BEANUTILS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573379#action_12573379 ] Niall Pemberton commented on BEANUTILS-307: --- OK its been a while since I looked at the java beans spec - my first thought is you should be using XValue as the property name instead of xValue. BeanUtils.setProperty(...) not working for property xValue (see description for reason) - Key: BEANUTILS-307 URL: https://issues.apache.org/jira/browse/BEANUTILS-307 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.8.0-BETA Environment: linux, jdk 1.6, beanutils 1.8 beta Reporter: Alexander Koppelhuber setting values for a property that has one lower case character at the beginning followed by an upper case character does not work. for example xValue or zIndex. The reason (as far as I found out) is as follows: Introspector.getBeanInfo() gets the property names from the get/set methods. In Introspector.getTargetPropertyInfo() the following code creates a PropertyDescriptor: pd = new PropertyDescriptor(decapitalize(name.substring(3)),..) decapitalize() says when there is more than one character and both the first and second characters are upper case, we leave it alone... which results in the name = XValue for the method getXValue() so setProperty(...) does not find a descriptor for xValue and cannot call the setXValue method I think this issue is not limited to 1.8 beta but also to earlier versions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-362: - Attachment: ExtendedMessageFormatTest.java Attaching a test case for ExtendedMessageFormat that I think should replace the existing four test classes. Note this includes a couple of tests for custom sub-formats which currently fail. Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, ExtendedMessageFormatTest.java, FormatFactory.java Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened LANG-362: -- OK I have a couple of points - Custom sub-formats are not supported - so if I embed a custom format in a choice format it throws an IllegalArgumentException. Do we want to support that scenario or document clearly that it doesn't work? (I did make this point in https://issues.apache.org/jira/browse/LANG-362?focusedCommentId=12564290#action_12564290) - Now the setFormats(), setFormat(), and setFormatByArgumentIndex() all throw UnsupportedOperationException I don't see the need for the logic to re-create the pattern - much simpler to just cache the pattern the EMF was created with and return that value in toPattern() - or am I missing something? - the test cases could (and IMO should) be simpler - currently there are four classes to test EMF (AbstractMessageFormatTest, ExtendedMessageFormatBaselineTest, MessageFormatExtensionTest. and MessageFormatTest) and I don't see why we don't just have one ExtendedMessageFormatTest). Tests are often a good way to look at how something works - so the simpler the better both for those maintaining it and users wanting to understand how to use it. Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, FormatFactory.java Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572966#action_12572966 ] Niall Pemberton commented on LANG-362: -- OK I've commited my test case: http://svn.apache.org/viewvc?view=revrevision=631639 Mind if I delete the other four? - AbstractMessageFormatTest - ExtendedMessageFormatBaselineTest - MessageFormatExtensionTest - MessageFormatTest Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, ExtendedMessageFormatTest.java, FormatFactory.java Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-285) Wish : method unaccent
[ https://issues.apache.org/jira/browse/LANG-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-285: - Attachment: LANG-285-unaccent-using-Collator.patch Perhaps an alternative to using a Map of characters is to use a Collator to compare characters to the standard 26 latin chars? http://java.sun.com/j2se/1.3/docs/api/java/text/Collator.html Attaching LANG-285-unaccent-using-Collator.patch which does this and includes Guillaume Coté's test case - which it passes. Wish : method unaccent -- Key: LANG-285 URL: https://issues.apache.org/jira/browse/LANG-285 Project: Commons Lang Issue Type: New Feature Reporter: Guillaume Coté Priority: Minor Fix For: 3.0 Attachments: LANG-285-unaccent-using-Collator.patch, MapBuilder.java, unaccent.patch, UnnacentMap.java 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-118) Change forceDelete API to return the boolean success
[ https://issues.apache.org/jira/browse/IO-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570196#action_12570196 ] Niall Pemberton commented on IO-118: I don't see the point of this now since deleteQuietly was introduced in 1.4 - why break compatibility on forceDelete to make it work like deleteQuietly - when people can just use deleteQuietly? Seems to me like we now provide two good options with both forceDelete() and deleteQuietly() for whatever people prefer - either return a boolean or throw an exception. I think this ticket just predated deleteQuietly() (IO-135) and we should now close it as WONT FIX. Change forceDelete API to return the boolean success Key: IO-118 URL: https://issues.apache.org/jira/browse/IO-118 Project: Commons IO Issue Type: Improvement Affects Versions: 1.3.1 Reporter: Henri Yandell Fix For: 2.x (Though I imagine it'll be 2.0 for API versioning, but reporting anyway). Would be nice to return the boolean that the delete method returns in forceDelete. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-156) add methods normalizePreserveSepartor and normalizePreserverSepartorNoEndseparator
[ https://issues.apache.org/jira/browse/IO-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570208#action_12570208 ] Niall Pemberton commented on IO-156: Do we really need this - you can use the normalize() / normalizeNoEndSeparator() methods in combination with either separatorsToWindows() or separatorsToUnix() to achieve this. add methods normalizePreserveSepartor and normalizePreserverSepartorNoEndseparator -- Key: IO-156 URL: https://issues.apache.org/jira/browse/IO-156 Project: Commons IO Issue Type: New Feature Affects Versions: 1.3.2 Reporter: Michael Priority: Minor Those are the same methods as normalize(String filename) and normalizeNoEndSeparator(String filename) but without converting path separator to the platform. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-192) Operator precedence driven parser
[ https://issues.apache.org/jira/browse/MATH-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569730#action_12569730 ] Niall Pemberton commented on MATH-192: -- Just to clarify - this is currently part of the matheclipse sourceforge project? http://www.matheclipse.org/ Also was the parser generated using JavaCC or ANTLR or some other such tool - if so which? Operator precedence driven parser -- Key: MATH-192 URL: https://issues.apache.org/jira/browse/MATH-192 Project: Commons Math Issue Type: New Feature Environment: Tested with commons-math-1.2-RC1-src Reporter: Axel Kramer Priority: Minor Attachments: parser.zip Attached are sources for an operator precedence driven parser as described here: http://en.wikipedia.org/wiki/Operator-precedence_parser At the moment the used syntax for the math expressions is very similar to the Mathematica input syntax and must probably be reworked for the common maths needs. Mainly the parser is driven by the arrays HEADER_STRINGS, OPERATOR_STRINGS and OPERATORS in the: org.matheclipse.parser.operator.ASTNodeFactory class. There's a utility class org.matheclipse.parser.util.GenerateOperatorArrays which generates the above arrays for operator sets defined in a textfile like for example /org.matheclipse.parser/eval/src/operators.txt JUnit test classes for testing the pure parser without any evaluations: /org.matheclipse.parser.test/src/org/matheclipse/parser/test/AllParserTests.java JUnit test classes for testing the evaluation in double or Complex calculation mode: /org.matheclipse.parser.test/src/org/matheclipse/parser/test/eval/AllEvalTests.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-294) BeanUtilsBean.setProperty() does not support nested map
[ https://issues.apache.org/jira/browse/BEANUTILS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-294: -- Fix Version/s: 1.8.0 Yes you're right, I'll put this on the list for 1.8.0 BeanUtilsBean.setProperty() does not support nested map --- Key: BEANUTILS-294 URL: https://issues.apache.org/jira/browse/BEANUTILS-294 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.8.0-BETA Reporter: Stephen Leung Priority: Critical Fix For: 1.8.0 I tried to call BeanUtilsBean.setProperty() with a DynaActionForm as the bean and someMap(x)(y) as the name. In BeanUtilsBean.setProperty(), after the while loop at line 900, target became null and name became = (y). And consequently IllegalArgumentException is thrown at line 930 when setProperty() tried to getPropertyDescriptor() of a null bean. Specifically, the following is the stack trace. Could somebody look into it? Thanks. java.lang.IllegalArgumentException: No bean specified at org.apache.common.beanutils.PropertyUtilsBean.getPropertyDescriptor(PropertyUtilsBean.java:871) at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:930) at org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:829) at org.apache.commons.beanutils.BeanUtils.populate(BeanUtilsBean.java:433) at org.apache.struts.util.RequestUtils.pouplate(RequestUtils.java:467) .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-298) MethodUtils.getAccessibleMethod(Method method) could not find right public method
[
https://issues.apache.org/jira/browse/BEANUTILS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated BEANUTILS-298:
--
Fix Version/s: 1.8.0
MethodUtils.getAccessibleMethod(Method method) could not find right public
method
-
Key: BEANUTILS-298
URL: https://issues.apache.org/jira/browse/BEANUTILS-298
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0, 1.8.0-BETA
Environment: Java 1.5, Windows XP
Reporter: Roman Mukhin
Priority: Minor
Fix For: 1.8.0
Let assume follows:
public interface IX {
getName();
}
class BaseX {
public getName();
}
class ImplX extends BaseX implements IX {
}
For some reason I do not want that BaseX implements IX, but if we have a bean
of type ImplX we can call getName().
PropertyUtils.getProperty(beanOfTypeBaseX, name) could not get the value,
because the method MethodUtils.getAccessibleMethod(Method method) looks up
only throunght supercalsses and interfaces of implementing class but not the
subclasses and interfaces that they implement!
So PropertyUtils.getProperty(beanOfTypeBaseX, name) throws an Exception
that the method is not accessible, but at the same time I can call
beanOfTypeBaseX.getName()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-301) In ArrayConverter, the allowedChars array should (possibly) include the underscore character
[ https://issues.apache.org/jira/browse/BEANUTILS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-301. --- Resolution: Won't Fix In ArrayConverter, the allowedChars array should (possibly) include the underscore character Key: BEANUTILS-301 URL: https://issues.apache.org/jira/browse/BEANUTILS-301 Project: Commons BeanUtils Issue Type: Improvement Components: ConvertUtils Converters Affects Versions: 1.8.0-BETA Environment: All Reporter: Martin Bartlett Priority: Minor An array value passed as: this_is_my_first_value,this_is_my_second_value should (could: please) result in a two-element array - currently the _ is not recognized as a word character and thus results in the StreamTokenizer splitting each string at the underscore. Maybe ALL Java symbol characters should be recognized? This would avoid unnecessary quoting ala this_is_my_first_value,this_is_my_second_value (note there is also a BUG related to this, since parsing the above string also results in an NPE in the current BETA- report to follow) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-303) Merge Capabilities
[ https://issues.apache.org/jira/browse/BEANUTILS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-303: -- Fix Version/s: LATER THAN 1.8.0 Merge Capabilities -- Key: BEANUTILS-303 URL: https://issues.apache.org/jira/browse/BEANUTILS-303 Project: Commons BeanUtils Issue Type: Improvement Reporter: Rodrigo di Lorenzo Lopes Priority: Minor Fix For: LATER THAN 1.8.0 Attachments: patch.txt Original Estimate: 24h Remaining Estimate: 24h BeanUtils doesn't offer an adequate way to merge values from two JavaBeans. Ex: From different sources, let there be two partially populated JavaBeans (each in different properties) . How to combine these JavaBeans ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-409) StringUtils.isText to check in a null safe way if a String has (real) text
[ https://issues.apache.org/jira/browse/LANG-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568247#action_12568247 ] Niall Pemberton commented on LANG-409: -- Validator has GenericValidator.minLength(String, int) - but it doesn't do the ignoring whitespace bit: http://tinyurl.com/2ne6qk StringUtils.isText to check in a null safe way if a String has (real) text -- Key: LANG-409 URL: https://issues.apache.org/jira/browse/LANG-409 Project: Commons Lang Issue Type: Improvement Reporter: Jörg Gottschling Priority: Minor I used something similar from the Spring Framework and it was useful. I suggest two methods where the second is a little more advanced then theirs. First a method StringUtils.isText(String text) : boolean which checks if the String is not null and contains a least one not whitespace character. (In Spring it's hasText, but isText seams to be more consistent within commons lang.) The second method could be StringUtils.isText(String text, int n) : boolean which checks if the String is not null and contains a least n not whitespace characters. Question: What happens if a (stupid ;-) developer checks for -5 characters? I think it should throw an IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-305) PropertyUtilsBean.isWritable() returns false when the property is mapped and there is a mapped write method available
[
https://issues.apache.org/jira/browse/BEANUTILS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-305.
---
Resolution: Duplicate
Fix Version/s: 1.8.0-BETA
PropertyUtilsBean.isWritable() returns false when the property is mapped and
there is a mapped write method available
--
Key: BEANUTILS-305
URL: https://issues.apache.org/jira/browse/BEANUTILS-305
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: jdk 1.4.2
Reporter: Stuart Brown
Fix For: 1.8.0-BETA
PropertyUtilsBean.isWritable returns false when there is a mapped property
write method. It does not do this on indexed properties, I am not sure why
mapped properties would be handled differently, but I do not believe they
should be. Also this means there is no method in the class to test for
writable mapped properties.
Also PropertyUtilsBean.isReadable has the same issue and the fix is similar.
Following code should work :
1185Method writeMethod = desc.getWriteMethod();
1186if ((writeMethod == null)
1187(desc instanceof IndexedPropertyDescriptor)) {
1188writeMethod = ((IndexedPropertyDescriptor)
desc).getIndexedWriteMethod();
1189}
+ if (( writeMethod==null)
+ (desc instanceof MappedPropertyDescriptor)) {
+ writeMethod =
((MappedPropertyDescriptor)desc).getMappedWriteMethod();
+}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-119) Convenience Builder for creating complex FileFilter conditions
[ https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567596#action_12567596 ] Niall Pemberton commented on IO-119: @Gary - I agree with your general principles about clarity and writing and maintaining code, but IMO you can have both - terse code thats clearer. Personally I dislike IDE code formatting, it always seems to screw up and make things less readable - which IMO is a bigger hinderance to maintaining the code long term. Anyway, this is an alternative option for people who do prefer it - those that don't can use the FileFilterUtils or the implementations directly. Convenience Builder for creating complex FileFilter conditions Key: IO-119 URL: https://issues.apache.org/jira/browse/IO-119 Project: Commons IO Issue Type: Improvement Components: Filters Affects Versions: 1.3.1 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.x Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java I'd like to add a new convenience builder class (FileFilterBuilder) to make it easier to create complex FileFilter using Commons IO's IOFileFilter implementations. Heres an example of how it can be used to create a IOFileFilter for the following conditions: - Either, directories which are not hidden and not named .svn - or, files which have a suffix of .java IOFileFilter filter = FileFilterBuilder.orBuilder() .and().isDirectory().isHidden(false).not().name(.svn).end() .and().isFile().suffix(.java).end() .getFileFilter(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-119) Convenience Builder for creating complex FileFilter conditions
[ https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567488#action_12567488 ] Niall Pemberton commented on IO-119: Mine is reduce typing, makes it very easy with auto-complete - just keep hitting period and one or two letters to add another condition. Convenience Builder for creating complex FileFilter conditions Key: IO-119 URL: https://issues.apache.org/jira/browse/IO-119 Project: Commons IO Issue Type: Improvement Components: Filters Affects Versions: 1.3.1 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.x Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java I'd like to add a new convenience builder class (FileFilterBuilder) to make it easier to create complex FileFilter using Commons IO's IOFileFilter implementations. Heres an example of how it can be used to create a IOFileFilter for the following conditions: - Either, directories which are not hidden and not named .svn - or, files which have a suffix of .java IOFileFilter filter = FileFilterBuilder.orBuilder() .and().isDirectory().isHidden(false).not().name(.svn).end() .and().isFile().suffix(.java).end() .getFileFilter(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567485#action_12567485 ] Niall Pemberton commented on MATH-180: -- I don't think so, I re-built math yesteray and checked that nothing had changed OSGi wise (and none of the commits since affect it) - so looks good to go from my PoV Add support for OSGi to Commons Math Key: MATH-180 URL: https://issues.apache.org/jira/browse/MATH-180 Project: Commons Math Issue Type: Task Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Fix For: 1.2 I saw mentioned that Commons Math 1.2 is on the horizon and it would be good to add support for OSGi. Is the release likely to be done using Maven1 or Maven2? I can provide a patch for either, but if its m2 then will probably hold off until nearer the release to see if we get anything done in the commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-119) Convenience Builder for creating complex FileFilter conditions
[ https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-119: --- Attachment: (was: FileFilterBuilder.java) Convenience Builder for creating complex FileFilter conditions Key: IO-119 URL: https://issues.apache.org/jira/browse/IO-119 Project: Commons IO Issue Type: Improvement Components: Filters Affects Versions: 1.3.1 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.x Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java I'd like to add a new convenience builder class (FileFilterBuilder) to make it easier to create complex FileFilter using Commons IO's IOFileFilter implementations. Heres an example of how it can be used to create a IOFileFilter for the following conditions: - Either, directories which are not hidden and not named .svn - or, files which have a suffix of .java IOFileFilter filter = FileFilterBuilder.orBuilder() .and().isDirectory().isHidden(false).not().name(.svn).end() .and().isFile().suffix(.java).end() .getFileFilter(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-119) Convenience Builder for creating complex FileFilter conditions
[ https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-119: --- Attachment: (was: FileFilterBuilderTestCase.java) Convenience Builder for creating complex FileFilter conditions Key: IO-119 URL: https://issues.apache.org/jira/browse/IO-119 Project: Commons IO Issue Type: Improvement Components: Filters Affects Versions: 1.3.1 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.x Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java I'd like to add a new convenience builder class (FileFilterBuilder) to make it easier to create complex FileFilter using Commons IO's IOFileFilter implementations. Heres an example of how it can be used to create a IOFileFilter for the following conditions: - Either, directories which are not hidden and not named .svn - or, files which have a suffix of .java IOFileFilter filter = FileFilterBuilder.orBuilder() .and().isDirectory().isHidden(false).not().name(.svn).end() .and().isFile().suffix(.java).end() .getFileFilter(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-139) StringBuilder Writer implementation
[ https://issues.apache.org/jira/browse/IO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-139. Resolution: Fixed Fix Version/s: (was: 2.x) 2.0 Fixed: http://svn.apache.org/viewvc?view=revrevision=619141 StringBuilder Writer implementation --- Key: IO-139 URL: https://issues.apache.org/jira/browse/IO-139 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.0 Attachments: StringBuilderWriter.java, StringBuilderWriterTest.java This implementation, as an alternative to java.io.StringWriter, provides an un-synchronized (i.e. for use in a single thread) implementation for better performance. StringBuilder is a JDK 1.5+ feature -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-155) use NIO for copyFile when running on java 1.4
[ https://issues.apache.org/jira/browse/IO-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-155. Resolution: Fixed Fix Version/s: (was: 2.x) 2.0 Assignee: Niall Pemberton Fixed thanks http://svn.apache.org/viewvc?view=revrevision=619156 use NIO for copyFile when running on java 1.4 - Key: IO-155 URL: https://issues.apache.org/jira/browse/IO-155 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 1.4 Reporter: nicolas de loof Assignee: Niall Pemberton Priority: Trivial Fix For: 2.0 Attachments: IO-155.patch CopyFile can rely on java.nio when runtime is java 1.4 + -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-140) IO 2.0 - Move to JDK 1.5
[ https://issues.apache.org/jira/browse/IO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-140: --- Fix Version/s: (was: 2.x) 2.0 Summary: IO 2.0 - Move to JDK 1.5 (was: IO 2.0 - remove deprecations and move to JDK 1.5) OK I've applied all the JDK 1.5 changes, except I added the CharSequence flavour methods to IOUtils and FileUtils, rather than changing the signature of the existing methods: - Use generics: http://svn.apache.org/viewvc?view=revrevision=619103 - Use StringBuilder (non-sync) in place of StringBuffer : http://svn.apache.org/viewvc?view=revrevision=619112 - Add new JDK 1.5 Read/Writer methods: http://svn.apache.org/viewvc?view=revrevision=619135 - Add CharSequence flavour methods to IOUtils / FileUtils: http://svn.apache.org/viewvc?view=revrevision=619188 - Replace StringWriter with StringBuilderWriter in IOUtils: http://svn.apache.org/viewvc?view=revrevision=619195 So far AFAIK none of these are incompatible changes - clirr is only showing an issue with the LineIterator next() method returning a String rather than Object - but I think this is a false positive? Stephen mentioned a couple of other points (Collections to Iterable, and removing arrays) here: http://commons.markmail.org/message/xcplvzf3p4odbckx IO 2.0 - Move to JDK 1.5 Key: IO-140 URL: https://issues.apache.org/jira/browse/IO-140 Project: Commons IO Issue Type: Wish Reporter: Niall Pemberton Fix For: 2.0 Attachments: IO-2.0-deprecate-and-jdk5.patch I just created IO-139 for a StringBuilder Writer implementation that requies JDK 1.5. So I thought I would look at the impact on IO of 1) Removing all deprecations and 2) Making appropriate JDK 1.5 changes (generics, using StringBuilder and new Appendable for Writers). Below is a summary, thought it could be a starting point for discussion about IO 2.0 1) DEPRECATIONS - CopyUtils - FileCleaner - WildcardFilter - FileSystemUtils freeSpace(String) - IOUtils toByteArray(String), toString(byte[]), toString(byte[], String) 2) JDK 1.5 - ConditionalFileFilter List (and also AndFileFilter and OrFileFilter implementations - getFileFilters() and setFileFilters() use generic ListIOFileFilter - Constructor for NameFileFilter, PrefixFileFilter, SuffixFileFilter, WildcardFileFilter use generic ListString - replace StringBuffer with StringBuilder where appropriate (FilenameUtils, FileSystemUtils, HexDump,IOUtils - FileUtils - convertFileCollectionToFileArray() -- CollectionFile - listFiles() -- CollectionFile - listFiles() -- CollectionFile - writeStringToFile String--CharSequence (JDK 1.4+) - ProxyReader - add read(CharBuffer) - IOUtils - readLines(Reader) return ListString - toInputStream(String) -- toInputStream(CharSequence) (JDK 1.4+) - write(String data, OutputStream) and write(StringBuffer data, OutputStream) -- write(CharSequence data, OutputStream) - write(String, Writer) and write(StringBuffer, Writer) -- write(CharSequence data, Writer) - LineIterator Iterator -- IteratorString - NullWriter - add Appendable methods - ProxyWriter - add Appendable methods -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-154) Throw IllegalArgumentException when parameters are null (and explicitly checked)
[ https://issues.apache.org/jira/browse/IO-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-154. Resolution: Won't Fix Don't think there was any interest in doing this Throw IllegalArgumentException when parameters are null (and explicitly checked) Key: IO-154 URL: https://issues.apache.org/jira/browse/IO-154 Project: Commons IO Issue Type: Improvement Affects Versions: 1.4 Reporter: Niall Pemberton Priority: Minor Fix For: 2.x IO is currently inconsistent with it explicitly throwing either a NullPointerException or IllegalArgumentException when a methods arguments are null - see discussion on IO-77. Review and change IO to only explcitly throw IllegalArgumentException in this scenario. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[
https://issues.apache.org/jira/browse/IO-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-89.
---
Resolution: Won't Fix
Inconsistency in SizeFileFilter and AgeFileFilter implementations
-
Key: IO-89
URL: https://issues.apache.org/jira/browse/IO-89
Project: Commons IO
Issue Type: Bug
Components: Filters
Affects Versions: 1.2
Reporter: Niall Pemberton
Priority: Minor
Fix For: 2.x
Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
AgeFileFilter.
In SizeFileFilter, using an acceptLarger parameter of true actually accepts
files with a size equal to and larger, whereas
specifying an acceptLarger parameter of false only accepts smaller files.
The same is true for AgeFileFilter, using an acceptOlder parameter of true
actually accepts files either the same age or older, whereas
specifying an acceptOlder parameter of false only accepts newer files.
A big benefit of resolving these inconsistencies would mean that creating
filters for any condition (i.e. , , =, = or =) becomes
alot easier. For example if the AgeFileFilter did only do either newer or
older, then creating a filters for the same age or older
or the same age or younger could be done in the following way:
IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
false));
IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
true));
For SizeFileFilter I propose changing the logic to the following:
if (acceptLarger) {
return file.length() = size;
} else {
return file.length() = size;
}
(This would mean that new SizeFileFilter(cutoff) would operate the same way)
I have added isOlderFile() methods to FileUtils and propose that
AgeFileFilter is changed to the following:
if (acceptOlder) {
return FileUtils.isFileOlder(file, cutoff);
} else {
return FileUtils.isFileNewer(file, cutoff);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-302) NPE in ArrayConverter when converting a non-quoted string with underscores to a string array
[ https://issues.apache.org/jira/browse/BEANUTILS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-302. --- Resolution: Fixed Fix Version/s: (was: 1.8.0-BETA) 1.8.0 Assignee: Niall Pemberton Thanks for reporting this, now fixed: http://svn.apache.org/viewvc?view=revrevision=618207 NPE in ArrayConverter when converting a non-quoted string with underscores to a string array Key: BEANUTILS-302 URL: https://issues.apache.org/jira/browse/BEANUTILS-302 Project: Commons BeanUtils Issue Type: Bug Components: ConvertUtils Converters Affects Versions: 1.8.0-BETA Environment: All Reporter: Martin Bartlett Assignee: Niall Pemberton Fix For: 1.8.0 An array value passed as: this_is_my_first_value,this_is_my_second_value causes an NPE after the first token is returned: java.lang.NullPointerException at org.apache.commons.beanutils.converters.ArrayConverter.parseElements(ArrayConverter.java:440) at org.apache.commons.beanutils.converters.ArrayConverter.convertToCollection(ArrayConverter.java:343) at org.apache.commons.beanutils.converters.ArrayConverter.convertToType(ArrayConverter.java:279) at org.apache.commons.beanutils.converters.AbstractConverter.convert(AbstractConverter.java:171) at org.apache.commons.beanutils.converters.ConverterFacade.convert(ConverterFacade.java:60) at org.apache.commons.beanutils.BeanUtilsBean.convert(BeanUtilsBean.java:1079) at org.apache.commons.beanutils.BeanUtilsBean.copyProperty(BeanUtilsBean.java:437) at org.apache.commons.beanutils.BeanUtilsBean.copyProperties(BeanUtilsBean.java:270) at org.apache.commons.beanutils.BeanUtils.copyProperties(BeanUtils.java:137) The parse list being built contains this. The sval field of the StreamTokenizer is indeed null - presumably because it has found the the underscore. Workaround is to quote the string. See BEANUTILS-301 for an improvement request to allow _ as part of the default word character set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565458#action_12565458 ] Niall Pemberton commented on LANG-362: -- Yes that would greatly simplify things - how does that sit though with something thats completely compatible with MessageFormat? Works for me, but I thought you wanted a drop in replacement? Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, FormatFactory.java Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-406) Add FractionFormat to oacl.text
[ https://issues.apache.org/jira/browse/LANG-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565266#action_12565266 ] niallp edited comment on LANG-406 at 2/3/08 8:47 PM: -- I'm not sure why we have Fraction in both Lang and Math - I guess historically they just evolved separately. The duplication does seem like a waste of effort though and Math IMO is a better location - also Math already has a FractionFormat implementation. Perhaps would be a good idea to compare both Fraction implementations and ensure that one supports all features of the other and then deprecate one. http://svn.apache.org/repos/asf/commons/proper/math/trunk/src/java/org/apache/commons/math/fraction/ http://svn.apache.org/repos/asf/commons/proper/lang/trunk/src/java/org/apache/commons/lang/math/ was (Author: niallp): I'm not sure why we have Fraction in both Lang and Math - I guess historically they just evolved separately. The duplication does seem like a waste of effort though and Math IMO is a better location - also Math already has a FractionFormat implementation. Perhaps would be a good idea to compare both Fraction implementations and ensure that one supports all features of the other and then deprecate one. Add FractionFormat to oacl.text --- Key: LANG-406 URL: https://issues.apache.org/jira/browse/LANG-406 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: FractionFormat.java, FractionFormatTest.java, FractionToString.patch.txt I'd like to add a FractionFormat implementation, capable of formatting Numbers including oacl.math.Fraction to fractions, and of parsing fraction representation (and standalone integers) into oacl.math.Fraction instances. Implementation and test forthcoming; opinions welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-406) Add FractionFormat to oacl.text
[ https://issues.apache.org/jira/browse/LANG-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565266#action_12565266 ] Niall Pemberton commented on LANG-406: -- I'm not sure why we have Fraction in both Lang and Math - I guess historically they just evolved separately. The duplication does seem like a waste of effort though and Math IMO is a better location - also Math already has a FractionFormat implementation. Perhaps would be a good idea to compare both Fraction implementations and ensure that one supports all features of the other and then deprecate one. Add FractionFormat to oacl.text --- Key: LANG-406 URL: https://issues.apache.org/jira/browse/LANG-406 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: FractionFormat.java, FractionFormatTest.java, FractionToString.patch.txt I'd like to add a FractionFormat implementation, capable of formatting Numbers including oacl.math.Fraction to fractions, and of parsing fraction representation (and standalone integers) into oacl.math.Fraction instances. Implementation and test forthcoming; opinions welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[
https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565260#action_12565260
]
Niall Pemberton commented on LANG-362:
--
You're right it hadn't hit my radar about toPattern() reconstructing the
pattern from internal state and so my suggestion reflects only half the
equation, i.e. pattern--Format and not Format--pattern.
The first thought I have about this is that one option would be to only support
toPattern() for 1) existing MessageFormat compatiblity (i.e. the four
standard built in formats) and 2) those configured through the pattern (i.e.
not non-standard formats configured using the setFormat() methods). I believe
this would be fairly straight forward to do and since EMF is providing a
mechanism for using any format thru' the pattern then the use of setFormat()
methods becomes unnecessary.
Having said that even if full toPattern() support is an absolute must I still
think the use of meta formats and the current implementation over-complicates
things and my thinking goes along the following lines:
- Using a meta Format implementation for the pattern--Format conversion is
confusing in itself. I think this is where my Factory suggestion has merit
since the idea of registering a format factory and then EMF looking-up a
registered factory to create a Format is much more straight forward concept for
users to grasp.
- The current implementation does this kind of look-up (using
NameKeyMetaFormat) but in an overcomplicated way - by creating an aggregated
MultiFormat which tries to parse using delegated NameKeyMetaFormat which in
turn delegates again if the format itself has arguments. Since the
FormatElement part of message format's pattern is always {index, FormatType,
args} then why have every meta-format repeatedly parse that info trying to
match - my suggestion involved EMF extracting out the FormatType, looking up a
registered factory for it and if found the factory then just parsing the
arguments component. Surely this is simpler and less error prone than having to
repeat the whole parsing of the FormatElement in every meta format?
- If I didn't convice you with my earlier reasoning about whether full
toPattern() support is really required then I think this can also be supported
using the factory concept. It would reguire the registry to be more than a
simple Map (i.e. be able to lookup a factory based on a Format, as well as
name) and the FormatFactory would need additional method(s) to support
re-creating the pattern - but I think that is doable as well.
Anyway I'm not wedded to my proposal (I generally try not to just throw out
criticism since IMO what counts at the ASF is not talking, but doing) and have
no problem it being dismissed - but I'm not convinced that what is there
currently should be included in an official release. I think the concept is
great, but supporting the code and users for this I think will be a headache
that we regret down the line.
Add ExtendedMessageFormat to org.apache.commons.lang.text
-
Key: LANG-362
URL: https://issues.apache.org/jira/browse/LANG-362
Project: Commons Lang
Issue Type: New Feature
Reporter: Matt Benson
Assignee: Matt Benson
Priority: Minor
Fix For: 2.4
Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt,
extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java,
FormatFactory.java
Discussed on dev@ (
http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL
PROTECTED] ); adding here for tracking purposes and in case anyone has any
serious objections to my implementation. Patch forthcoming...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564821#action_12564821 ] Niall Pemberton commented on MATH-180: -- I have configured the m2 build to add OSGi to the jar's manifest: http://svn.apache.org/viewvc?view=revrevision=617551 A few notes on this: - I did it manually adding manifest entries thru' the jar plugin configuration rather than the Felix bundleplugin. This was because the released bundleplugin adds alot of uses statements which when the next version of the bnd tool is available (Bnd 0.0.236) will not happen. - I did run the bundleplugin to check what it produced and used that as a basis to configure the manifest entires - Commons Logging is listed as a dependency, but only used thru' Commons Discovery. The bundleplugin didn't include it in the import statement, so I haven't either - Once we have a released commons parent with the bundleplugin configured we can remove the config I've added here for math Add support for OSGi to Commons Math Key: MATH-180 URL: https://issues.apache.org/jira/browse/MATH-180 Project: Commons Math Issue Type: Task Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Fix For: 1.2 I saw mentioned that Commons Math 1.2 is on the horizon and it would be good to add support for OSGi. Is the release likely to be done using Maven1 or Maven2? I can provide a patch for either, but if its m2 then will probably hold off until nearer the release to see if we get anything done in the commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-23) commons-parent-8 pom changes (OSGi)
[ https://issues.apache.org/jira/browse/COMMONSSITE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-23: --- Attachment: COMMONSSITE-23-commons-parent-v2.patch Attaching a new commons-parent patch - Net had examples packages and Launcher had default package classes - I changed the export instruction From * (i.e. export all packages to org.apache.commons.* - so we only export commons scoped packages. This was from feedback from Martin Oberhuber on the dev list - http://commons.markmail.org/message/zblr2p2yn4dujum4 commons-parent-8 pom changes (OSGi) --- Key: COMMONSSITE-23 URL: https://issues.apache.org/jira/browse/COMMONSSITE-23 Project: Commons All Issue Type: New Feature Components: Commons Parent Pom Reporter: Niall Pemberton Attachments: COMMONSSITE-23-commons-components-v1.patch, COMMONSSITE-23-commons-parent-v1.patch, COMMONSSITE-23-commons-parent-v2.patch Opening this to discuss changes for the next commons-parent release. The felix project has released the OSGi bundle plugin (version 1.2.0) and specifying that in commons-parent makes it easy for components to be OSGi enabled with little effort. Documentation about the plugin is here: http://felix.apache.org/site/maven-bundle-plugin-bnd.html Also, notes for Commons OSGi are here: http://wiki.apache.org/commons/CommonsOsgi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMMONSSITE-23) commons-parent-8 pom changes (OSGi)
[ https://issues.apache.org/jira/browse/COMMONSSITE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated COMMONSSITE-23: --- Attachment: (was: COMMONSSITE-23-commons-parent-v1.patch) commons-parent-8 pom changes (OSGi) --- Key: COMMONSSITE-23 URL: https://issues.apache.org/jira/browse/COMMONSSITE-23 Project: Commons All Issue Type: New Feature Components: Commons Parent Pom Reporter: Niall Pemberton Attachments: COMMONSSITE-23-commons-components-v1.patch, COMMONSSITE-23-commons-parent-v2.patch Opening this to discuss changes for the next commons-parent release. The felix project has released the OSGi bundle plugin (version 1.2.0) and specifying that in commons-parent makes it easy for components to be OSGi enabled with little effort. Documentation about the plugin is here: http://felix.apache.org/site/maven-bundle-plugin-bnd.html Also, notes for Commons OSGi are here: http://wiki.apache.org/commons/CommonsOsgi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564536#action_12564536 ] Niall Pemberton commented on MATH-181: -- I have no idea - it was in the original constructor and my math is rubbish compare to you guys. Specify the maximum of digits when parsing a Fraction - Key: MATH-181 URL: https://issues.apache.org/jira/browse/MATH-181 Project: Commons Math Issue Type: Improvement Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Attachments: MATH-181-FractionDigitsLimit-v2.patch, MATH-181-FractionDigitsLimit.patch, MATH-181-FractionMaxDenominator.patch Firstly, thanks for the Fraction code - I've adapated it for something I'm working on and I didn't have a clue how to convert a decimal to a fraction :) Excel spreadsheets have the facility to specify a fraction format where you specify the maximum number of denominator digits to display. So for example: format ?/? displays decimal values formatted in the range 1/2 to n/9 format ??/?? displays decimal values formatted in the range 1/2 to n/99 format ???/??? displays decimal values formatted in the range 1/2 to n/999 etc In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively for the above 3 formats. I'm attaching a patch for the Fraction class which adds a new constructor where the maximum number of digits can be specified, rather than the epsilon value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-366) add MultiFormat
[ https://issues.apache.org/jira/browse/LANG-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened LANG-366: -- I've had a look at the new MultiFormat and IMO it needs work before its ready to be in a release (and I would probably vote -1 on a release if included in its current state). The biggest issue IMO is that currently it doesn't always work: - Formatting: a special GuardedFormat had to be created in MultiFormatTest to get the testFormatNumber to pass because the date format can handle numbers. Looks to me like MultiFormat needs the logic in GuardedFormat otherwise users are going to hit exactly that problem. - Parsing: in certains situations, implementations such as DecimalFormat and SimpleDateFormat stop when they hit an invalid character and don't indicate an error. For example if I parse 1/1/1970 with an integer format, it doesn't cause an error and returns a number of value 1. So in the MultiFormatTest testParseDate only works when the date format is before the number format - reverse the order and the test fails. The solution IMO is to check that all of the parsed input String has been consumed. Other points are: - the tests for error conditions should be improved - Format implements Cloneable and therefore this implementation should implement the clone method and create a copy of the delegate array and clone each Format in it. add MultiFormat --- Key: LANG-366 URL: https://issues.apache.org/jira/browse/LANG-366 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Fix For: 2.4 Attachments: multiFormat.patch.txt this started as a part of LANG-362. That PR depends on this one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened LANG-362: -- I started looking at the extended message format - I like the concept but first impression is the implementation is over complex and difficult to work out what its doing. I will try to find some time to document in detail what I thinks wrong with it - but at this point I would vote -1 on a release of Lang that included it. Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-366) add MultiFormat
[ https://issues.apache.org/jira/browse/LANG-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-366: - Attachment: MultiFormat2.java Attaching an alternative implementation that resolves the issues I raised. Its not properly tested - but it works with the current MutliFormat test without the GuardedFormat and whichever way round the formats are specified. Also clone is implemented. add MultiFormat --- Key: LANG-366 URL: https://issues.apache.org/jira/browse/LANG-366 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Fix For: 2.4 Attachments: multiFormat.patch.txt, MultiFormat2.java this started as a part of LANG-362. That PR depends on this one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564290#action_12564290 ] Niall Pemberton commented on LANG-362: -- OK I'll try and summarize the overall approach of your implementation: - ExtendedMessageFormat strips out all the type and style components from format elements leaving only the 'placeholding' argument indexes and applies that pattern to the MessageFormat it extends - ExtendedMessageFormat then parses the pattern again extracting the format element components and uses the meta format to parse each format elements type and style and create a Format for that element - These created formats are then set for the MessageFormat it extends. This is obviously a simplification, but in order to achieve the second step (i.e. creating the formats) it requires combing all the meta format implementations into a MultiFormat to generate all the format types currently supported by MessageFormat, plus any custom format types. So we have meta format implementations for date, time and number - plus a factory for these standard types. On top of that we have NameKeyedMetaFormat for anyone wanting to implement a custom format type and a couple of abstract support classes. - MetaFormatSupport - MultiFormat - ExtendedMessageFormat - NameKeyedMetaFormat - DefaultMetaFormatFactory - DateMetaFormat - DateMetaFormatSupport - NumberMetaFormat - TimeMetaFormat Working out how this all hung together took me some time and I think it will be difficult for users to grasp, difficult to support (I tried looking at the test cases to see how it worked, but its not quick to see from them either - you have to scan thru' quite a bit of code to find a real example of what you want to do). IMO this can be a whole lot simpler - both in terms of code quantity and complexity and in terms of concepts for users to grasp: I believe we only need two types to support this functionality: - an ExtendedMessageFormat implementation - a (v. simple) FormatFactory interface The FormatFactory interface has a single method as follows: Format getFormat(String name, String arguments, Locale locale); It works something like this: - create a registry (i.e. java.util.Map) of additional format type factories (additional to what MessageFormat already supports). - create an ExtendedMessageFormat instance with the registry - parse the pattern and for any format element types that have a factory registered, remove the type and style components from the pattern and pass them to the factory to create the format. - apply the modified pattern and set the formats for any created I have hacked your ExtendedMessageFormat implementation to do this and will attach it here. Its not properly tested and doesn't handle sub-formats ATM, but I believe it proves the concept and will attach in a minute Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[
https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-362:
-
Attachment: DateFormatFactory.java
FormatFactory.java
ExtendedMessageFormat2.java
OK I'm attaching the following implementations
- ExtendedMessageFormat2
- FormatFactory
- DateFormatFactory
The DateFormatFactory is an example FormatFactory implementation that supports
the existing date and time format types, but also adds a new datetime
type. (btw its written as it is so that it can be used to implement Lang's
FastDateFormat implementation - by just overriding the protected methods).
So to use the new datetime type, all thats required is the following:
Map registry = new HashMap();
registry.put(datetime, new DateFormatFactory());
String pattern = Date: {0,date,short} Time: {0,time,medium} Date/Time:
{0,datetime,long};
ExtendedMessageFormat2 fmt = new ExtendedMessageFormat2(pattern,
registry);
System.out.println(fmt.format(new Object[] {new Date()}));
Note that the date and time types are not being handled by our custom
factory - the standard MessageFormat functionality is doing that. If we wanted
we could register custom formats for those standard types as well.
Maybe I'm missing something, but is this not achieving the same goal?
Add ExtendedMessageFormat to org.apache.commons.lang.text
-
Key: LANG-362
URL: https://issues.apache.org/jira/browse/LANG-362
Project: Commons Lang
Issue Type: New Feature
Reporter: Matt Benson
Assignee: Matt Benson
Priority: Minor
Fix For: 2.4
Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt,
extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java,
FormatFactory.java
Discussed on dev@ (
http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL
PROTECTED] ); adding here for tracking purposes and in case anyone has any
serious objections to my implementation. Patch forthcoming...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564293#action_12564293 ] Niall Pemberton commented on LANG-362: -- P.S. This is pretty much all your code with in ExtendedMessageFormat2 with a bit of simplification and couple of additions Add ExtendedMessageFormat to org.apache.commons.lang.text - Key: LANG-362 URL: https://issues.apache.org/jira/browse/LANG-362 Project: Commons Lang Issue Type: New Feature Reporter: Matt Benson Assignee: Matt Benson Priority: Minor Fix For: 2.4 Attachments: DateFormatFactory.java, extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, FormatFactory.java Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL PROTECTED] ); adding here for tracking purposes and in case anyone has any serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated MATH-181: - Attachment: MATH-181-FractionMaxDenominator.patch Thanks Luc - when I submitted this I was only thinking of my own simple use-case but perhaps its better (and allows finer grained control) to just be able to specify the maximum denominator value in the constructor - it avoids the overflow issue altogether. Attaching a patch, although it meets my needs as it is. Specify the maximum of digits when parsing a Fraction - Key: MATH-181 URL: https://issues.apache.org/jira/browse/MATH-181 Project: Commons Math Issue Type: Improvement Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Attachments: MATH-181-FractionDigitsLimit-v2.patch, MATH-181-FractionDigitsLimit.patch, MATH-181-FractionMaxDenominator.patch Firstly, thanks for the Fraction code - I've adapated it for something I'm working on and I didn't have a clue how to convert a decimal to a fraction :) Excel spreadsheets have the facility to specify a fraction format where you specify the maximum number of denominator digits to display. So for example: format ?/? displays decimal values formatted in the range 1/2 to n/9 format ??/?? displays decimal values formatted in the range 1/2 to n/99 format ???/??? displays decimal values formatted in the range 1/2 to n/999 etc In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively for the above 3 formats. I'm attaching a patch for the Fraction class which adds a new constructor where the maximum number of digits can be specified, rather than the epsilon value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-404) Add Calendar flavour format methods to DateFormatUtils
[ https://issues.apache.org/jira/browse/LANG-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-404. -- Resolution: Fixed Fixed http://svn.apache.org/viewvc?view=revrevision=615243 Add Calendar flavour format methods to DateFormatUtils -- Key: LANG-404 URL: https://issues.apache.org/jira/browse/LANG-404 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.4 Add Calendar flavour format methods to DateFormatUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-404) Add Calendar flavour format methods to DateFormatUtils
Add Calendar flavour format methods to DateFormatUtils -- Key: LANG-404 URL: https://issues.apache.org/jira/browse/LANG-404 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.4 Add Calendar flavour format methods to DateFormatUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562019#action_12562019 ] Niall Pemberton commented on MATH-181: -- Yes, I mostly just copied the existing constructor and didn't put any effort - sorry :( Its an either or situation and not optimal (which is why I made it private) - but it means that with a couple of slight modifications the same code can be (re)used either with an epsilon or specified max. denominator digits. I can either submit another patch with improved JavaDoc or spearate out the two cases, duplicating the double--fraction code. Which would you prefer? Specify the maximum of digits when parsing a Fraction - Key: MATH-181 URL: https://issues.apache.org/jira/browse/MATH-181 Project: Commons Math Issue Type: Improvement Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Attachments: MATH-181-FractionDigitsLimit.patch Firstly, thanks for the Fraction code - I've adapated it for something I'm working on and I didn't have a clue how to convert a decimal to a fraction :) Excel spreadsheets have the facility to specify a fraction format where you specify the maximum number of denominator digits to display. So for example: format ?/? displays decimal values formatted in the range 1/2 to n/9 format ??/?? displays decimal values formatted in the range 1/2 to n/99 format ???/??? displays decimal values formatted in the range 1/2 to n/999 etc In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively for the above 3 formats. I'm attaching a patch for the Fraction class which adds a new constructor where the maximum number of digits can be specified, rather than the epsilon value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562022#action_12562022 ] Niall Pemberton commented on MATH-180: -- OK, once the RM and tool (m1 or m2) is decided we can then sort out OSGi. Are there any packages of Commons Math that are consider for internal use and not really for end-users? I ask because you can specify Private-Package for those parts in OSGi and AIUI these are then not available to other bundles which import Math. Add support for OSGi to Commons Math Key: MATH-180 URL: https://issues.apache.org/jira/browse/MATH-180 Project: Commons Math Issue Type: Task Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Fix For: 1.2 I saw mentioned that Commons Math 1.2 is on the horizon and it would be good to add support for OSGi. Is the release likely to be done using Maven1 or Maven2? I can provide a patch for either, but if its m2 then will probably hold off until nearer the release to see if we get anything done in the commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-179) Fraction tests for double Constructor
Fraction tests for double Constructor - Key: MATH-179 URL: https://issues.apache.org/jira/browse/MATH-179 Project: Commons Math Issue Type: Test Reporter: Niall Pemberton Priority: Minor I was looking at borrowing some code from Fraction and the constructor that takes a double doesn't seem to have much tests. Attaching a patch - if I've missed something or these tests are a waste of time or its covered well elsewhere then please ignore this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-179) Fraction tests for double Constructor
[ https://issues.apache.org/jira/browse/MATH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561452#action_12561452 ] Niall Pemberton commented on MATH-179: -- Sorry ignore the m2 comment, must have been a one-off glitch - re-running works fine Fraction tests for double Constructor - Key: MATH-179 URL: https://issues.apache.org/jira/browse/MATH-179 Project: Commons Math Issue Type: Test Reporter: Niall Pemberton Priority: Minor Attachments: MATH-FractionConstructorDouble.patch I was looking at borrowing some code from Fraction and the constructor that takes a double doesn't seem to have much tests. Attaching a patch - if I've missed something or these tests are a waste of time or its covered well elsewhere then please ignore this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-180) Add support for OSGi to Commons Math
Add support for OSGi to Commons Math Key: MATH-180 URL: https://issues.apache.org/jira/browse/MATH-180 Project: Commons Math Issue Type: Task Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Fix For: 1.2 I saw mentioned that Commons Math 1.2 is on the horizon and it would be good to add support for OSGi. Is the release likely to be done using Maven1 or Maven2? I can provide a patch for either, but if its m2 then will probably hold off until nearer the release to see if we get anything done in the commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561482#action_12561482 ] Niall Pemberton commented on MATH-180: -- P.S. See http://wiki.apache.org/commons/CommonsOsgi Add support for OSGi to Commons Math Key: MATH-180 URL: https://issues.apache.org/jira/browse/MATH-180 Project: Commons Math Issue Type: Task Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Fix For: 1.2 I saw mentioned that Commons Math 1.2 is on the horizon and it would be good to add support for OSGi. Is the release likely to be done using Maven1 or Maven2? I can provide a patch for either, but if its m2 then will probably hold off until nearer the release to see if we get anything done in the commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-181) Specify the maximum of digits when parsing a Fraction
Specify the maximum of digits when parsing a Fraction - Key: MATH-181 URL: https://issues.apache.org/jira/browse/MATH-181 Project: Commons Math Issue Type: Improvement Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Attachments: MATH-181-FractionDigitsLimit.patch Firstly, thanks for the Fraction code - I've adapated it for something I'm working on and I didn't have a clue how to convert a decimal to a fraction :) Excel spreadsheets have the facility to specify a fraction format where you specify the maximum number of denominator digits to display. So for example: format ?/? displays decimal values formatted in the range 1/2 to n/9 format ??/?? displays decimal values formatted in the range 1/2 to n/99 format ???/??? displays decimal values formatted in the range 1/2 to n/999 etc In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively for the above 3 formats. I'm attaching a patch for the Fraction class which adds a new constructor where the maximum number of digits can be specified, rather than the epsilon value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated MATH-181: - Attachment: MATH-181-FractionDigitsLimit.patch Specify the maximum of digits when parsing a Fraction - Key: MATH-181 URL: https://issues.apache.org/jira/browse/MATH-181 Project: Commons Math Issue Type: Improvement Affects Versions: 1.1 Reporter: Niall Pemberton Priority: Minor Attachments: MATH-181-FractionDigitsLimit.patch Firstly, thanks for the Fraction code - I've adapated it for something I'm working on and I didn't have a clue how to convert a decimal to a fraction :) Excel spreadsheets have the facility to specify a fraction format where you specify the maximum number of denominator digits to display. So for example: format ?/? displays decimal values formatted in the range 1/2 to n/9 format ??/?? displays decimal values formatted in the range 1/2 to n/99 format ???/??? displays decimal values formatted in the range 1/2 to n/999 etc In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively for the above 3 formats. I'm attaching a patch for the Fraction class which adds a new constructor where the maximum number of digits can be specified, rather than the epsilon value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-402) OSGi-ify Lang
[ https://issues.apache.org/jira/browse/LANG-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-402: - Attachment: LANG-402-OSGi-jar-maniest.patch At the moment the Felix project's maven2 bundle plugin has not been released - so attaching a patch to configure the m2 build through the jar plugin. If Lang 2.4 is going to use m1, I can supply a patch for that too. See also http://wiki.apache.org/commons/CommonsOsgi OSGi-ify Lang - Key: LANG-402 URL: https://issues.apache.org/jira/browse/LANG-402 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Assignee: Niall Pemberton Fix For: 2.4 Attachments: LANG-402-OSGi-jar-maniest.patch Pre-release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-22) Maven2 Plugin to generate custom component pages
[ https://issues.apache.org/jira/browse/COMMONSSITE-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559917#action_12559917 ] Niall Pemberton commented on COMMONSSITE-22: Generated Download Page Notes: - Some binary distros use the -bin prefix for binary distros, others don't - Commons BeanUtils and Collections currently have two release versions listed - Daemon only has tar.gz files - Latka lists a single zip file - Email also lists javadoc and sources jars - Launcher has examples distros - Proxy has a download page, but isn't yet released Maven2 Plugin to generate custom component pages Key: COMMONSSITE-22 URL: https://issues.apache.org/jira/browse/COMMONSSITE-22 Project: Commons All Issue Type: Improvement Components: Commons Build Reporter: Niall Pemberton Assignee: Niall Pemberton I've been playing with a Maven2 Ant plugin which is a possible solution for generating the component's download pages - currently handled by m1. As an addition it also does custom Issue Tracking pages, of the style most m1 sites use (and better than the current m2 generated one). The advantage of this plugin is that it creates the page in the component's site - which is better IMO than having a page in commons general outside the component's site. I'm going to add this to the sandbox shortly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-240) Broken link for 'Naming' project in docs
[ https://issues.apache.org/jira/browse/DBCP-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560274#action_12560274 ] Niall Pemberton commented on DBCP-240: -- Its still there in directory's site structure, but something is preventing it being seen. And in svn its in their dormant-subprojects area: http://svn.apache.org/viewvc/directory/sandbox/dormant-subprojects/ Broken link for 'Naming' project in docs Key: DBCP-240 URL: https://issues.apache.org/jira/browse/DBCP-240 Project: Commons Dbcp Issue Type: Bug Reporter: Luis Parravicini Priority: Minor The page at http://commons.apache.org/dbcp/guide/jndi-howto.html talks about Naming, with a link to http://directory.apache.org/subprojects/naming/index.html which gives a 404. Moreover, I couldn't find the Naming subproject from Apache Directory, it seems it doesn't exist anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-257) Add new splitByWholeSeparatorPreserveAllTokens() methods to StringUtils
[ https://issues.apache.org/jira/browse/LANG-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-257: - Summary: Add new splitByWholeSeparatorPreserveAllTokens() methods to StringUtils (was: [Patch] - added new methods to StringUtil) Add new splitByWholeSeparatorPreserveAllTokens() methods to StringUtils --- Key: LANG-257 URL: https://issues.apache.org/jira/browse/LANG-257 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.1 Reporter: Cameron Whitehead Priority: Minor Fix For: 2.4 Attachments: LANG-257.patch, StringUtils-enhancements.patch I added two methods I found helpful. public static String[] splitByWholeSeparatorPreserveAllTokens(String str, String separator, int max) public static String[] splitByWholeSeparatorPreserveAllTokens(String str, String separator) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) Add convenience moveFile() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557648#action_12557648
]
Niall Pemberton commented on IO-77:
---
Thanks Nicolas, can you open a new issue ticket for this please? Also this will
have to go into the next Commons IO release because, although we have added new
JKD 1.4 dependant implementations in Commons IO we are retaining compatibility
with JDK 1.3 (thru' the compiler source/target options) for existing classes
such as IOUtils.
Also your patch has *alot* of noise in it - as was the last one which took me a
while to remove all the un-related/formatting changes. Small focused patches
are much more likely to get applied since they take much less effort to review.
Add convenience moveFile() / moveDirectory methods to FileUtils
---
Key: IO-77
URL: https://issues.apache.org/jira/browse/IO-77
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.3.2
Environment: Operating System: other
Platform: Other
Reporter: nicolas de loof
Assignee: Niall Pemberton
Priority: Minor
Fix For: 1.4
Attachments: IO-77-nio.patch, IO-77.patch, patch_io.txt
I'm using FileUtils as it partially solves the missing move method for File,
that is so simple to do in unix shell.
A full implementation in FileUtils may be great :
static boolean FileUtils.move(File src, File dest)
throws IOException
{
boolean rename = src.renameTo(dest);
if (!rename)
{
copyFile(file, dest);
file.delete();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-155) use NIO for copyFile when running on java 1.4
[ https://issues.apache.org/jira/browse/IO-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-155: --- Fix Version/s: (was: 1.4) AFTER-1.4 IMO better to not have the JDK 1.4 hack and just put this into the next release. Also we have a small script to check that JDK 1.4 features haven't crept in (excluding the new implementations that require it) - if we put this in then we would have to exclude IOUtils and everything that depends on it - then theres no way for people reviewing the release to verify easily for themselves that we are still JDK 1.3 compliant for everything except the four new implementations. use NIO for copyFile when running on java 1.4 - Key: IO-155 URL: https://issues.apache.org/jira/browse/IO-155 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 1.4 Reporter: nicolas de loof Priority: Trivial Fix For: AFTER-1.4 Attachments: IO-155.patch CopyFile can rely on java.nio when runtime is java 1.4 + -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) Add convenience moveFile() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557666#action_12557666
]
Niall Pemberton commented on IO-77:
---
OK I reverted to NPE since only Henri voted since and other committers wanted
it that way:
http://svn.apache.org/viewvc?view=revrevision=610810
Add convenience moveFile() / moveDirectory methods to FileUtils
---
Key: IO-77
URL: https://issues.apache.org/jira/browse/IO-77
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.3.2
Environment: Operating System: other
Platform: Other
Reporter: nicolas de loof
Assignee: Niall Pemberton
Priority: Minor
Fix For: 1.4
Attachments: IO-77-nio.patch, IO-77.patch, patch_io.txt
I'm using FileUtils as it partially solves the missing move method for File,
that is so simple to do in unix shell.
A full implementation in FileUtils may be great :
static boolean FileUtils.move(File src, File dest)
throws IOException
{
boolean rename = src.renameTo(dest);
if (!rename)
{
copyFile(file, dest);
file.delete();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-153. Resolution: Fixed Assignee: Stephen Colebourne FileWriter that accepts an encoding --- Key: IO-153 URL: https://issues.apache.org/jira/browse/IO-153 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Stephen Colebourne Assignee: Stephen Colebourne Priority: Minor Fix For: 1.4 Attachments: FileWriterWithEncoding.java, io-FileWriterWithEncoding.patch Amazingly, even in JDK6 there are no constructors on FileWriter that accept an encoding. Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-154) Throw IllegalArgumentException when parameters are null (and explicitly checked)
Throw IllegalArgumentException when parameters are null (and explicitly checked) Key: IO-154 URL: https://issues.apache.org/jira/browse/IO-154 Project: Commons IO Issue Type: Improvement Affects Versions: 1.4 Reporter: Niall Pemberton Priority: Minor Fix For: AFTER-1.4 IO is currently inconsistent with it explicitly throwing either a NullPointerException or IllegalArgumentException when a methods arguments are null - see discussion on IO-77. Review and change IO to only explcitly throw IllegalArgumentException in this scenario. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-127) Move to a minimum of JDK 1.4
[ https://issues.apache.org/jira/browse/IO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-127. Resolution: Fixed Assignee: Niall Pemberton Move to a minimum of JDK 1.4 Key: IO-127 URL: https://issues.apache.org/jira/browse/IO-127 Project: Commons IO Issue Type: Task Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.4 Attachments: commons-io-jdk-1_3-check.patch There was a discussion a while back on moving Commons IO to a minimum JDK version of 1.4 - see [1] below. The majority view was this was a good idea. Jorg Schaible suggested[2] that the compiler options be kept at JDK 1.3 so that, apart from new JDK 1.4 dependant features, Commons IO would still operate under JDK 1.3. This seems like a good idea and resolves the issue of whether this would require a major version change. There was also a view that we should move to JDK 1.5 instead - I have no issue with that, but would advocate that theres no point in doing so until there are people wanting to commit JDK 1.5 dependant features. This change is targeted at Commons IO 1.4 - and a Commons IO 1.3 branch has been created for anyone still desiring future JDK 1.3 only releases. [1] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) Add convenience moveFille() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557184#action_12557184
]
Niall Pemberton commented on IO-77:
---
So where are we at with this, I'd like to put it to bed.
I don't want to take out the explict check/throw for nulls since its a PITA for
users to have to look up a line number to find out whats causing the exception.
Consistency is good, but seems that we don't have that - so I suggest we leave
it as it is (throwing IllegalArgumentException) and sort out the consistency in
IO 2.0 - I've created IO-154 to remember to do this.
If this isn't satisfactory then I suggest people vote on this here:
[ ] -1 I don't agree, revert to throwing NullpointerException
[ ] +1 leave it as it is throwing IllegalArgumentException
Add convenience moveFille() / moveDirectory methods to FileUtils
Key: IO-77
URL: https://issues.apache.org/jira/browse/IO-77
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.3.2
Environment: Operating System: other
Platform: Other
Reporter: nicolas de loof
Assignee: Niall Pemberton
Priority: Minor
Fix For: 1.4
Attachments: IO-77.patch, patch_io.txt
I'm using FileUtils as it partially solves the missing move method for File,
that is so simple to do in unix shell.
A full implementation in FileUtils may be great :
static boolean FileUtils.move(File src, File dest)
throws IOException
{
boolean rename = src.renameTo(dest);
if (!rename)
{
copyFile(file, dest);
file.delete();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-137) Added method for getting InputStream from ByteArrayOutputStream IOUtils avoiding unnecessary array allocation and copy
[ https://issues.apache.org/jira/browse/IO-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-137: --- Fix Version/s: (was: 1.4) AFTER-1.4 Added method for getting InputStream from ByteArrayOutputStream IOUtils avoiding unnecessary array allocation and copy Key: IO-137 URL: https://issues.apache.org/jira/browse/IO-137 Project: Commons IO Issue Type: New Feature Components: Streams/Writers, Utilities Affects Versions: 1.3.2 Environment: Any OS with appropriate JVM Reporter: Nikunj Trivedi Fix For: AFTER-1.4 Attachments: baos_to_inputstream.patch, baos_toIstream.patch Patch inclues following two methods and test cases for both. 1) New Method: ByteArrayOutputStream.toInputStream ByteArrayOutputStream exposes its byte buffers by toByteArray(), which creates a fresh buffer and copy existing data to it. A new method toInputStream() available in patch returns the current contents of baos, as an InputStream, avoiding unnecessary allocation and copying. 2) New Method: IOUtils.toFullyBufferedInputStream There are situations where the InputStream source is available and it has to be passed to different modules for processing. It is needed to fetch the full contents of the InputStream in internal buffer(IOUtils.toByteArray() ), convert this buffer to ByteArrayInputStream and use that stream instead. But this is wasteful since toByteArray() requires one fresh allocation and copy operation. New method copies InputStream to ByteArrayOutputStream and returns baos.toInputStream(), avoiding unnecessary memory allocation and copy. Testcases are available in respective classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) Add convenience moveFille() / moveDirectory methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557285#action_12557285
]
Niall Pemberton commented on IO-77:
---
@Henri
LineIterator was in the last release - also isFileNewer() / isFileOlder() in
FileUtils throw IllegalArgumentException so we have code in the vicinity doing
both. Also what do you think about changing them all to IAE in IO 2.0
(backward-incompatible JDK 1.5 version) as I propose in IO-154 - I think if
we're going to do that then we should create the minimum disruption and use IAE
here. IMO a -1 vote here should also be a -1 vote to IO-154.
Add convenience moveFille() / moveDirectory methods to FileUtils
Key: IO-77
URL: https://issues.apache.org/jira/browse/IO-77
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.3.2
Environment: Operating System: other
Platform: Other
Reporter: nicolas de loof
Assignee: Niall Pemberton
Priority: Minor
Fix For: 1.4
Attachments: IO-77.patch, patch_io.txt
I'm using FileUtils as it partially solves the missing move method for File,
that is so simple to do in unix shell.
A full implementation in FileUtils may be great :
static boolean FileUtils.move(File src, File dest)
throws IOException
{
boolean rename = src.renameTo(dest);
if (!rename)
{
copyFile(file, dest);
file.delete();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-77) [io] add a convenience FileUtils.move(File src, File dest)
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556577#action_12556577
]
Niall Pemberton commented on IO-77:
---
Thanks for the new patch Nicolas - I've applied it with some modifications:
http://svn.apache.org/viewvc?view=revrevision=609622
I renamed the move method to moveFile so that its consistent with the
existing copyFile/copyDirectory methods we have. I also added
moveFileToDirectory, moveDirectoryToDirectory and moveToDirectory method
flavours with the same idea as their copy equivalents.
Theres are a few other minor changes (like throwing IOException instead of
IllegalArgumentException) . I'll leave this open for now for feedback
Niall
[io] add a convenience FileUtils.move(File src, File dest)
--
Key: IO-77
URL: https://issues.apache.org/jira/browse/IO-77
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.0
Environment: Operating System: other
Platform: Other
Reporter: nicolas de loof
Priority: Minor
Fix For: 1.4
Attachments: IO-77.patch, patch_io.txt
I'm using FileUtils as it partially solves the missing move method for File,
that is so simple to do in unix shell.
A full implementation in FileUtils may be great :
static boolean FileUtils.move(File src, File dest)
throws IOException
{
boolean rename = src.renameTo(dest);
if (!rename)
{
copyFile(file, dest);
file.delete();
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-21) commons-parent-6 pom changes
[ https://issues.apache.org/jira/browse/COMMONSSITE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556811#action_12556811 ] Niall Pemberton commented on COMMONSSITE-21: @Dennis - sorry for annoying you Dennis - I heres my opnions on your four points: - 1) I agree - 2) I agree - 3) I agree, but it also says .txt extensions are acceptable and the best solution IMO for Commons is an alternative bundle as I propose in MRRESOURCES-31[1] - 4) I disagree because I don't think any components should be using it until the issues with generation and what to do about the source/binary distros are resolved. So is there a way to include the generated NOTICE / LICENSE files in the source and binary distros? [1] http://jira.codehaus.org/browse/MRRESOURCES-31 commons-parent-6 pom changes Key: COMMONSSITE-21 URL: https://issues.apache.org/jira/browse/COMMONSSITE-21 Project: Commons All Issue Type: Improvement Components: Commons Parent Pom Reporter: Niall Pemberton Attachments: commons-valdiator-generated-NOTICE.txt, COMMONSSITE-21-commons-parent-pom-v1.patch, COMMONSSITE-21-commons-parent-pom-v2.patch Opening this ticket to discuss changes for Version 6 of the commons-parent pom. See thread: http://tinyurl.com/39eo9z for related discussion/issues -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-51) Throttled input and output stream classes
[ https://issues.apache.org/jira/browse/IO-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-51: -- Fix Version/s: (was: 1.4) AFTER-1.4 This was discussed recently in the following thread: http://commons.markmail.org/message/zooudrehscpblxul Needs review and (possibly) some work so moving to post 1.4 Throttled input and output stream classes - Key: IO-51 URL: https://issues.apache.org/jira/browse/IO-51 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Affects Versions: 1.0 Environment: Operating System: other Platform: All Reporter: Gareth Davis Priority: Minor Fix For: AFTER-1.4 Attachments: throttle-example.jar, throttle-source.jar, throttle-source.jar Additional classes for the commons-io package. Three new classes, the new test classes and one example class. io.Limiter - Core class shared between the input and output streams that provides the central functions for the throttle io streams io.input.ThrottledInputStream - Input Stream implementation io.output.ThrottledOutputStream - Output Stream implementation Gareth -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-153) FileWriter that accepts an encoding
[ https://issues.apache.org/jira/browse/IO-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556438#action_12556438 ] Niall Pemberton commented on IO-153: On the JDK 1.3 compatibility the majority agreed with moving to JDK 1.4 for the IO 1.4 release (see IO-127) - however we haven't actually done that, but instead retained JDK 1.3 compatibility for all but three (and this would be a fourth) new implementations. I could understand it i it for this implementation if it was just the FileOutputStream constructor, which gains nothing from using it - but theres an opportunity to support the new Charset and CharsetEncoder features in this impl - so I think we should do that. I don't understand you saying that using ProxyWriter is more complex - doing so removes the need for the writer variable and the following seven methods: - write(int) - write(char[]) - write(char[], int, int) - write(String) - write(String, int, int) - flush() - close() ...and replaces that with a dummy object in the super constructor and initializing one additional variable (i.e. lock) - how is that more complex? Another point is that JDK 1.5 introduces new append() methods in JDK 1.5 which I suggested we should add to ProxyWriter when we move to JDK 1,5 (see IO-140) - which with no effort this impl. would inherit - although maybe delegating to the proxy's append() methods compared to letting the default Writer append methods (which call write()) is a minor point. The main one is no duplicating code around. FileWriter that accepts an encoding --- Key: IO-153 URL: https://issues.apache.org/jira/browse/IO-153 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Stephen Colebourne Priority: Minor Fix For: 1.4 Attachments: FileWriterWithEncoding.java, io-FileWriterWithEncoding.patch Amazingly, even in JDK6 there are no constructors on FileWriter that accept an encoding. Attached is a patch to add FileWriterWithEncoding -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-148) IOException with constructors which take a cause
[ https://issues.apache.org/jira/browse/IO-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-148. Resolution: Fixed Assignee: Gary Gregory IOException with constructors which take a cause Key: IO-148 URL: https://issues.apache.org/jira/browse/IO-148 Project: Commons IO Issue Type: New Feature Reporter: Niall Pemberton Assignee: Gary Gregory Priority: Minor Fix For: 1.4 Add an IOException implementation that has constructors which take a cause (see TIKA-104). Constructors which take a cause (Throwable) were not added to IOException until JDK 1.6 but the initCause() method was added to Throwable in JDK 1.4. We should copy the Tika implementation and test case here: http://svn.apache.org/repos/asf/incubator/tika/trunk/src/main/java/org/apache/tika/exception/CauseIOException.java http://svn.apache.org/repos/asf/incubator/tika/trunk/src/test/java/org/apache/tika/exception/CauseIOExceptionTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-105) Add a FileUtils copyDirectory method that makes use of FileFilter
[ https://issues.apache.org/jira/browse/IO-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-105. Resolution: Fixed Fixed: http://svn.apache.org/viewvc?view=revrevision=609471 Add a FileUtils copyDirectory method that makes use of FileFilter - Key: IO-105 URL: https://issues.apache.org/jira/browse/IO-105 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: Henri Yandell Assignee: Niall Pemberton Priority: Minor Fix For: 1.4 Attachments: IO-105-FileUtils_copyDirectory_filtered.patch 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-21) commons-parent-6 pom changes
[ https://issues.apache.org/jira/browse/COMMONSSITE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556209#action_12556209 ] Niall Pemberton commented on COMMONSSITE-21: @Stephen +1 @Dennis - various thoughts: - Commons is currently consistent and IMO should remain that way - both in how NL are named and handled - Renaming NL files is alot of make-work (ant and m1 builds would break) - an alternative Apache NL package with .txt extenstions would be preferrable to renaming - What about source and binary distros? They should contain the same NL files - how could the generated ones get into those distros? - seems like wasted effort to change something that works and is simple and esp. to something that doesn't currently work well commons-parent-6 pom changes Key: COMMONSSITE-21 URL: https://issues.apache.org/jira/browse/COMMONSSITE-21 Project: Commons All Issue Type: Improvement Components: Commons Parent Pom Reporter: Niall Pemberton Attachments: commons-valdiator-generated-NOTICE.txt, COMMONSSITE-21-commons-parent-pom-v1.patch, COMMONSSITE-21-commons-parent-pom-v2.patch Opening this ticket to discuss changes for Version 6 of the commons-parent pom. See thread: http://tinyurl.com/39eo9z for related discussion/issues -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-141) Infinite loop on FileUtils.copyDirectory when the destination directory is within the source directory
[ https://issues.apache.org/jira/browse/IO-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-141: --- Fix Version/s: 1.4 Assignee: Niall Pemberton Summary: Infinite loop on FileUtils.copyDirectory when the destination directory is within the source directory (was: [IO][PATCH] Infinite loop on FileUtils.copyDirectory when the destination directory is within the source directory) Infinite loop on FileUtils.copyDirectory when the destination directory is within the source directory -- Key: IO-141 URL: https://issues.apache.org/jira/browse/IO-141 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3.2 Environment: Win XP Reporter: Mark Bryan Yu Assignee: Niall Pemberton Priority: Critical Fix For: 1.4 Attachments: fix_recursion_bug.patch When you attempt to copy a directory and the destination directory is inside the source directory an inifinite loop occurs in the copyDirectory causing Commons-IO to create a folder w/o stopping until its reaches OS limitation. This code will recreate the bug: FileUtils.copyDirectory(new File(C:\\temp\\test-io\\a\\.), new File(C:\\temp\\test-io\\a\\. + File.separator + new Date().getTime())); Make sure C:\temp\test-io\a exists -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-141) Infinite loop on FileUtils.copyDirectory when the destination directory is within the source directory
[ https://issues.apache.org/jira/browse/IO-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-141. Resolution: Fixed Mark, Thanks for the patch Mark, but there are two issues with it. Firstly it only resolves the recusion issue when copying to a directory directly below the destination (i.e child), but not for deeper levels (i.e. grandchild or below). Secondly its inconsistent IMO since it only partially copies the source directory and should IMO be ignoring only directories or files created by the copy. I have applied an alternative solution to fix this which deals with the above two issues http://svn.apache.org/viewvc?rev=609147view=rev: Infinite loop on FileUtils.copyDirectory when the destination directory is within the source directory -- Key: IO-141 URL: https://issues.apache.org/jira/browse/IO-141 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3.2 Environment: Win XP Reporter: Mark Bryan Yu Assignee: Niall Pemberton Priority: Critical Fix For: 1.4 Attachments: fix_recursion_bug.patch When you attempt to copy a directory and the destination directory is inside the source directory an inifinite loop occurs in the copyDirectory causing Commons-IO to create a folder w/o stopping until its reaches OS limitation. This code will recreate the bug: FileUtils.copyDirectory(new File(C:\\temp\\test-io\\a\\.), new File(C:\\temp\\test-io\\a\\. + File.separator + new Date().getTime())); Make sure C:\temp\test-io\a exists -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-138) CharSequence Reader implementation
[ https://issues.apache.org/jira/browse/IO-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-138. Resolution: Fixed CharSequence Reader implementation -- Key: IO-138 URL: https://issues.apache.org/jira/browse/IO-138 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.4 Attachments: CharSequenceReader.java, CharSequenceReaderTest.java Reader implementation that handles any CharSequence (String, StringBuffer, StringBuilder or CharBuffer) - an alternative to java.io.StringReader which only caters for String. CharSequence is a JDK 1.4+ feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-148) IOException with constructors which take a cause
[ https://issues.apache.org/jira/browse/IO-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556246#action_12556246 ] Niall Pemberton commented on IO-148: Renamed to IOExceptionWithCause: http://svn.apache.org/viewvc?view=revrevision=609159 IOException with constructors which take a cause Key: IO-148 URL: https://issues.apache.org/jira/browse/IO-148 Project: Commons IO Issue Type: New Feature Reporter: Niall Pemberton Priority: Minor Fix For: 1.4 Add an IOException implementation that has constructors which take a cause (see TIKA-104). Constructors which take a cause (Throwable) were not added to IOException until JDK 1.6 but the initCause() method was added to Throwable in JDK 1.4. We should copy the Tika implementation and test case here: http://svn.apache.org/repos/asf/incubator/tika/trunk/src/main/java/org/apache/tika/exception/CauseIOException.java http://svn.apache.org/repos/asf/incubator/tika/trunk/src/test/java/org/apache/tika/exception/CauseIOExceptionTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-152) Add ByteArrayOutputStream.readFrom(InputStream)
[ https://issues.apache.org/jira/browse/IO-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556248#action_12556248 ] Niall Pemberton commented on IO-152: I find the method name readFrom confusing as its actually writing to the ByteArrayOutputStream - why not just write(InputStream)? Add ByteArrayOutputStream.readFrom(InputStream) --- Key: IO-152 URL: https://issues.apache.org/jira/browse/IO-152 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Jukka Zitting Priority: Minor Fix For: 1.4 Attachments: IO-152.patch It would be useful to have a ByteArrayOutputStream.readFrom(InputStream) method to mirror the existing writeTo(OutputStream) method. A call like baos.readFrom(in) would be semantically the same as IOUtils.copy(in, baos), but would avoid an extra in-memory copy of the stream contents, as it could read bytes from the input stream directly into the internal ByteArrayOutputStream buffers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-144) Add a compare method to IOCase
[ https://issues.apache.org/jira/browse/IO-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-144. Resolution: Fixed Assignee: Niall Pemberton Add a compare method to IOCase -- Key: IO-144 URL: https://issues.apache.org/jira/browse/IO-144 Project: Commons IO Issue Type: Improvement Affects Versions: 1.3.2 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-105) Add a FileUtils.copyDirectoryStructure method
[ https://issues.apache.org/jira/browse/IO-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-105: --- Attachment: IO-105-FileUtils_copyDirectory_filtered.patch I suggest a more generic/powerful solution - new copyDirectory() methods that take a java.io.FileFilter: public static void copyDirectory(File srcDir, File destDir, FileFilter filter) public static void copyDirectory(File srcDir, File destDir, FileFilter filter, boolean preserveFileDate) Copying a directory structure can then be achieved in the following way: FileUtils.copyDirectory(srcDir, destDir, DirectoryFileFilter.DIRECTORY) Attaching a patch which does this Add a FileUtils.copyDirectoryStructure method - Key: IO-105 URL: https://issues.apache.org/jira/browse/IO-105 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: Henri Yandell Fix For: AFTER-1.4 Attachments: IO-105-FileUtils_copyDirectory_filtered.patch 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. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-143) Add Singleton Constants to several stream classes
[ https://issues.apache.org/jira/browse/IO-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-143: --- Summary: Add Singleton Constants to several stream classes (was: [PATCH] Added Singleton Constants in several stream classes) Add Singleton Constants to several stream classes - Key: IO-143 URL: https://issues.apache.org/jira/browse/IO-143 Project: Commons IO Issue Type: Improvement Components: Streams/Writers Environment: jvm compliant os Reporter: Nikunj Trivedi Assignee: Niall Pemberton Fix For: 1.4 Attachments: closed_input_stream.patch, closed_output_stream.patch, null_output_stream.patch, null_writer.patch, singleton.patch I have added singleton constants in following four classes which should have been singleton. ClosedInputStream ClosedOutputStream NullOutputStream NullWriter We may also make it a singleton by keeping constructor private, if required. Please comment/commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-143) Add Singleton Constants to several stream classes
[ https://issues.apache.org/jira/browse/IO-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-143. Resolution: Fixed Add Singleton Constants to several stream classes - Key: IO-143 URL: https://issues.apache.org/jira/browse/IO-143 Project: Commons IO Issue Type: Improvement Components: Streams/Writers Environment: jvm compliant os Reporter: Nikunj Trivedi Assignee: Niall Pemberton Fix For: 1.4 Attachments: closed_input_stream.patch, closed_output_stream.patch, null_output_stream.patch, null_writer.patch, singleton.patch I have added singleton constants in following four classes which should have been singleton. ClosedInputStream ClosedOutputStream NullOutputStream NullWriter We may also make it a singleton by keeping constructor private, if required. Please comment/commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-119) Convenience Builder for creating complex FileFilter conditions
[ https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-119: --- Fix Version/s: (was: 1.4) AFTER-1.4 Convenience Builder for creating complex FileFilter conditions Key: IO-119 URL: https://issues.apache.org/jira/browse/IO-119 Project: Commons IO Issue Type: Improvement Components: Filters Affects Versions: 1.3.1 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: AFTER-1.4 Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java I'd like to add a new convenience builder class (FileFilterBuilder) to make it easier to create complex FileFilter using Commons IO's IOFileFilter implementations. Heres an example of how it can be used to create a IOFileFilter for the following conditions: - Either, directories which are not hidden and not named .svn - or, files which have a suffix of .java IOFileFilter filter = FileFilterBuilder.orBuilder() .and().isDirectory().isHidden(false).not().name(.svn).end() .and().isFile().suffix(.java).end() .getFileFilter(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-79) [IO][PATCH] - file and directory pollers
[ https://issues.apache.org/jira/browse/IO-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-79: -- Fix Version/s: (was: 1.4) AFTER-1.4 [IO][PATCH] - file and directory pollers Key: IO-79 URL: https://issues.apache.org/jira/browse/IO-79 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 1.1 Environment: Operating System: other Platform: Other Reporter: Jim Harrington Priority: Minor Fix For: AFTER-1.4 Attachments: file_directory_poller.jar Add classes that will monitor a file/directory and notify registered observers creation, deletion and content change events occur. Source is in the attachement file_directory_poller.jar as they are all new files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-145) File Comparator implementations
[ https://issues.apache.org/jira/browse/IO-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-145. Resolution: Fixed File Comparator implementations --- Key: IO-145 URL: https://issues.apache.org/jira/browse/IO-145 Project: Commons IO Issue Type: New Feature Affects Versions: 1.3.2 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.4 Attachments: DefaultFileComparator.java, ExtensionFileComparator.java, LastModifiedFileComparator.java, LengthFileComparator.java, NameFileComparator.java, PathFileComparator.java, ReverseFileComparator.java Add file comparator implementations - prompted by IO-142 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-128: --- Fix Version/s: (was: 1.4) AFTER-1.4 Moving this to post 1.4 - needs someone to step up and do the work NPE on FilenameUtils.equalsNormalizedOnSystem() --- Key: IO-128 URL: https://issues.apache.org/jira/browse/IO-128 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 Reporter: Antonio Gallardo Assignee: Niall Pemberton Fix For: AFTER-1.4 Attachments: IO-128-v2.patch The following code in commons-io (1.3.2) throws an NPE exception: org.apache.commons.io.FilenameUtils .equalsNormalizedOnSystem( //a.html, //ab.html); And here is the exception: java.lang.NullPointerException: The strings must not be null at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) at org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) at CodeSnippet_32.run(CodeSnippet_32.java:4) at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) at org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) I think it is wrong a message The strings must not be null, since there is not a null string involved in the call. Interesting is if both or 1 of the strings is null, it did not throws an exception. Additional comment from Niall Pemberton (on the dev mail list): The problem is that the FilenameUtils's normalize(String) method returns null if it thinks the file names are invalid - which in your case it seems to be doing so for both file names. So I guess theres two issues here - you're right the error is misleading and FilenameUtils should check the names again after calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-142) Retrieve Directory File List in Timestamp Order
[ https://issues.apache.org/jira/browse/IO-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556310#action_12556310 ] Niall Pemberton commented on IO-142: I have added the Comparator implementations from IO-145: http://svn.apache.org/repos/asf/commons/proper/io/trunk/src/java/org/apache/commons/io/comparator/ So is there anything left to do for this? Retrieve Directory File List in Timestamp Order --- Key: IO-142 URL: https://issues.apache.org/jira/browse/IO-142 Project: Commons IO Issue Type: New Feature Components: Utilities Environment: Java SE 5 - Windows, Linux Reporter: Al Scherer I searched your current Commons-IO issues/feature requests and did not find the following so I'd like to propose it as a feature request. Given a filename filter and dir name, the method would return a ListFile of the files that match the filter in last-modified timestamp order. Sun explicitly does not provide this functionality - from the Sun Java SE 5 API Javadocs, File's listFiles() method descriptions include the following disclaimer: There is no guarantee that the name strings in the resulting array will appear in any specific order; they are not, in particular, guaranteed to appear in alphabetical order. I needed the files in last-modified order so I wrote code to do it and would be glad to share the code with the commons project if you feel it would be useful. The signature is: - public ListFile getFileListInTimestampOrder(FilenameFilter filter, String dirName) I've already written, tested and used code to do this. There are additional flavors that might be worthwhile, too. - public ListFile getFileListInTimestampOrderReversed(FilenameFilter filter, String dirName) - public ListFile getFileListInNameOrder(FilenameFilter filter, String dirName) - public ListFile getFileListInNameOrderReversed(FilenameFilter filter, String dirName) BTW, I originally posted this on commons-lang but was given feedback that it might be a better fit here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-145) File Comparator implementations
[ https://issues.apache.org/jira/browse/IO-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-145: --- Fix Version/s: (was: AFTER-1.4) 1.4 I've removed the use of JDK 1.5 generics and changed the reverse implementation to package scoped. Also I renamed LengthFileComparator to SizeFileComparator and added an option to sum the size of the contents for a directory. http://svn.apache.org/viewvc?view=revrevision=609243 File Comparator implementations --- Key: IO-145 URL: https://issues.apache.org/jira/browse/IO-145 Project: Commons IO Issue Type: New Feature Affects Versions: 1.3.2 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.4 Attachments: DefaultFileComparator.java, ExtensionFileComparator.java, LastModifiedFileComparator.java, LengthFileComparator.java, NameFileComparator.java, PathFileComparator.java, ReverseFileComparator.java Add file comparator implementations - prompted by IO-142 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[
https://issues.apache.org/jira/browse/IO-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated IO-89:
--
Fix Version/s: (was: 1.4)
AFTER-1.4
Inconsistency in SizeFileFilter and AgeFileFilter implementations
-
Key: IO-89
URL: https://issues.apache.org/jira/browse/IO-89
Project: Commons IO
Issue Type: Bug
Components: Filters
Affects Versions: 1.2
Reporter: Niall Pemberton
Priority: Minor
Fix For: AFTER-1.4
Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
AgeFileFilter.
In SizeFileFilter, using an acceptLarger parameter of true actually accepts
files with a size equal to and larger, whereas
specifying an acceptLarger parameter of false only accepts smaller files.
The same is true for AgeFileFilter, using an acceptOlder parameter of true
actually accepts files either the same age or older, whereas
specifying an acceptOlder parameter of false only accepts newer files.
A big benefit of resolving these inconsistencies would mean that creating
filters for any condition (i.e. , , =, = or =) becomes
alot easier. For example if the AgeFileFilter did only do either newer or
older, then creating a filters for the same age or older
or the same age or younger could be done in the following way:
IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
false));
IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
true));
For SizeFileFilter I propose changing the logic to the following:
if (acceptLarger) {
return file.length() = size;
} else {
return file.length() = size;
}
(This would mean that new SizeFileFilter(cutoff) would operate the same way)
I have added isOlderFile() methods to FileUtils and propose that
AgeFileFilter is changed to the following:
if (acceptOlder) {
return FileUtils.isFileOlder(file, cutoff);
} else {
return FileUtils.isFileNewer(file, cutoff);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-105) Add a FileUtils.copyDirectoryStructure method
[ https://issues.apache.org/jira/browse/IO-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-105: --- Fix Version/s: (was: AFTER-1.4) 1.4 Add a FileUtils.copyDirectoryStructure method - Key: IO-105 URL: https://issues.apache.org/jira/browse/IO-105 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: Henri Yandell Fix For: 1.4 Attachments: IO-105-FileUtils_copyDirectory_filtered.patch 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. - You can reply to this email to add a comment to the issue online.
