[jira] [Commented] (CSV-211) CSVFormat.format trims last delimiter if the delimiter is a white space
[
https://issues.apache.org/jira/browse/CSV-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050062#comment-16050062
]
Gary Gregory commented on CSV-211:
--
Hi Alpesh,
Thank you for your report.
Are you available to provide a (failing) unit test along with a fix. You can
use a patch file or a GitHub PR.
Gary
> CSVFormat.format trims last delimiter if the delimiter is a white space
> ---
>
> Key: CSV-211
> URL: https://issues.apache.org/jira/browse/CSV-211
> Project: Commons CSV
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Any.
>Reporter: Alpesh Kulkarni
>Priority: Minor
>
> The function CSVFormat.format() trims off the last delimiter if the delimiter
> is a white space character and the value in the last column is null.
> {code:java}
> public String format(Object... values) {
> StringWriter out = new StringWriter();
> try {
> (new CSVPrinter(out, this)).printRecord(values);
> return out.toString().trim();
> } catch (IOException var4) {
> throw new IllegalStateException(var4);
> }
> }
> {code}
> For example, consider the following records (\t = tab)-
> ID{color:red}\t{color}Name{color:red}\t{color}Country{color:red}\t{color}Age
> 1{color:red}\t{color}John Doe{color:red}\t{color}USA{color:red}\t{color}20
> 2{color:red}\t{color}Jane Doe{color:red}\t{color}USA{color:red}\t{color}
> The CSVFormat.format() on both the rows returns the following -
> ID{color:red}\t{color}Name{color:red}\t{color}Country{color:red}\t{color}Age
> 1{color:red}\t{color}John Doe{color:red}\t{color}USA{color:red}\t{color}20
> 2{color:red}\t{color}Jane Doe{color:red}\t{color}USA
> Note that there is a missing delimiter for the last column in the second
> record.
> This usually causes schema mismatch when we try and read back the CSV file as
> there is one less column in all the rows which have a null at the end.
> I feel the trim() is unnecessary while returning *out.toString()*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050055#comment-16050055 ] Thomas Vandahl commented on JCS-178: I already committed this as a preliminary fix. Actually, the setFacade() call shall be moved to the parent class where the actual looping takes place. In addition I would like to pull a few parameters straight and *add a test* so that things like this don't happen again. Early next week, I'd say. > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CSV-211) CSVFormat.format trims last delimiter if the delimiter is a white space
Alpesh Kulkarni created CSV-211:
---
Summary: CSVFormat.format trims last delimiter if the delimiter is
a white space
Key: CSV-211
URL: https://issues.apache.org/jira/browse/CSV-211
Project: Commons CSV
Issue Type: Bug
Affects Versions: 1.4
Environment: Any.
Reporter: Alpesh Kulkarni
Priority: Minor
The function CSVFormat.format() trims off the last delimiter if the delimiter
is a white space character and the value in the last column is null.
{code:java}
public String format(Object... values) {
StringWriter out = new StringWriter();
try {
(new CSVPrinter(out, this)).printRecord(values);
return out.toString().trim();
} catch (IOException var4) {
throw new IllegalStateException(var4);
}
}
{code}
For example, consider the following records (\t = tab)-
ID{color:red}\t{color}Name{color:red}\t{color}Country{color:red}\t{color}Age
1{color:red}\t{color}John Doe{color:red}\t{color}USA{color:red}\t{color}20
2{color:red}\t{color}Jane Doe{color:red}\t{color}USA{color:red}\t{color}
The CSVFormat.format() on both the rows returns the following -
ID{color:red}\t{color}Name{color:red}\t{color}Country{color:red}\t{color}Age
1{color:red}\t{color}John Doe{color:red}\t{color}USA{color:red}\t{color}20
2{color:red}\t{color}Jane Doe{color:red}\t{color}USA
Note that there is a missing delimiter for the last column in the second record.
This usually causes schema mismatch when we try and read back the CSV file as
there is one less column in all the rows which have a null at the end.
I feel the trim() is unnecessary while returning *out.toString()*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals
[
https://issues.apache.org/jira/browse/TEXT-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049916#comment-16049916
]
ASF GitHub Bot commented on TEXT-90:
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-text/pull/50#discussion_r122105816
--- Diff:
src/test/java/org/apache/commons/text/CharacterPredicatesTest.java ---
@@ -44,4 +44,77 @@ public void testDigits() {
assertFalse(CharacterPredicates.DIGITS.test('.'));
assertFalse(CharacterPredicates.DIGITS.test('L'));
}
+
+@Test
+public void testArabicNumerals() {
--- End diff --
TIL about JUnit theories :)
> Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic
> numerals
> ---
>
> Key: TEXT-90
> URL: https://issues.apache.org/jira/browse/TEXT-90
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.2
>
>
> I tried to migrate a project from RandomStringUtils to RandomStringGenerator
> today, but I found it hard to replace methods like
> RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.
> I believe it would ease migration from RandomStringUtils to
> RandomStringGenerator if CharacterPrecidates would offer more predicates.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals
[
https://issues.apache.org/jira/browse/TEXT-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049908#comment-16049908
]
ASF GitHub Bot commented on TEXT-90:
Github user jvz commented on a diff in the pull request:
https://github.com/apache/commons-text/pull/50#discussion_r122104232
--- Diff:
src/test/java/org/apache/commons/text/CharacterPredicatesTest.java ---
@@ -44,4 +44,77 @@ public void testDigits() {
assertFalse(CharacterPredicates.DIGITS.test('.'));
assertFalse(CharacterPredicates.DIGITS.test('L'));
}
+
+@Test
+public void testArabicNumerals() {
--- End diff --
This whole test looks repetitive enough to benefit from [parameterized
tests](https://github.com/junit-team/junit4/wiki/Parameterized-tests) or even
possibly [theories](https://github.com/junit-team/junit4/wiki/Theories).
> Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic
> numerals
> ---
>
> Key: TEXT-90
> URL: https://issues.apache.org/jira/browse/TEXT-90
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.2
>
>
> I tried to migrate a project from RandomStringUtils to RandomStringGenerator
> today, but I found it hard to replace methods like
> RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.
> I believe it would ease migration from RandomStringUtils to
> RandomStringGenerator if CharacterPrecidates would offer more predicates.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals
[
https://issues.apache.org/jira/browse/TEXT-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049907#comment-16049907
]
ASF GitHub Bot commented on TEXT-90:
Github user jvz commented on a diff in the pull request:
https://github.com/apache/commons-text/pull/50#discussion_r122104071
--- Diff: src/main/java/org/apache/commons/text/CharacterPredicates.java ---
@@ -48,5 +48,73 @@ public boolean test(int codePoint) {
public boolean test(int codePoint) {
return Character.isDigit(codePoint);
}
-}
+},
+
+/**
+ * Tests if the code points represents a number between 0 and 9.
+ *
+ * @since 1.2
+ */
+ARABIC_NUMERALS {
+@Override
+public boolean test(int codePoint) {
+return codePoint >= ZERO_CODEPOINT && codePoint <=
NINE_CODEPOINT;
+}
+},
+
+/**
+ * Tests if the code points represents a letter between a and z.
+ *
+ * @since 1.2
+ */
+ASCII_LOWERCASE_LETTERS {
+@Override
+public boolean test(int codePoint) {
+return codePoint >= LOWERCASE_A_CODEPOINT && codePoint <=
LOWERCASE_Z_CODEPOINT;
+}
+},
+
+/**
+ * Tests if the code points represents a letter between A and Z.
+ *
+ * @since 1.2
+ */
+ASCII_UPPERCASE_LETTERS {
+@Override
+public boolean test(int codePoint) {
+return codePoint >= UPPERCASE_A_CODEPOINT && codePoint <=
UPPERCASE_Z_CODEPOINT;
+}
+},
+
+/**
+ * Tests if the code points represents a letter between a and Z.
+ *
+ * @since 1.2
+ */
+ASCII_LETTERS {
+@Override
+public boolean test(int codePoint) {
+return ASCII_LOWERCASE_LETTERS.test(codePoint) ||
ASCII_UPPERCASE_LETTERS.test(codePoint);
+}
+},
+
+/**
+ * Tests if the code points represents a letter between a and Z or a
number between 0 and 9.
+ *
+ * @since 1.2
+ */
+ASCII_ALPHA_NUMERALS {
+@Override
+public boolean test(int codePoint) {
+return ASCII_LOWERCASE_LETTERS.test(codePoint) ||
ASCII_UPPERCASE_LETTERS.test(codePoint)
+|| ARABIC_NUMERALS.test(codePoint);
+}
+};
+
+private static final int NINE_CODEPOINT = 57;
--- End diff --
Wouldn't it make more sense to use an implicit widening on `'9'` to `int`
rather than hardcoded constants?
> Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic
> numerals
> ---
>
> Key: TEXT-90
> URL: https://issues.apache.org/jira/browse/TEXT-90
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.2
>
>
> I tried to migrate a project from RandomStringUtils to RandomStringGenerator
> today, but I found it hard to replace methods like
> RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.
> I believe it would ease migration from RandomStringUtils to
> RandomStringGenerator if CharacterPrecidates would offer more predicates.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-91) RandomStringGenerator should be able to generate a String with a random length
[ https://issues.apache.org/jira/browse/TEXT-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049903#comment-16049903 ] ASF GitHub Bot commented on TEXT-91: Github user jvz commented on the issue: https://github.com/apache/commons-text/pull/51 Looks good to me! > RandomStringGenerator should be able to generate a String with a random length > -- > > Key: TEXT-91 > URL: https://issues.apache.org/jira/browse/TEXT-91 > Project: Commons Text > Issue Type: New Feature >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (VFS-636) I wish that it support reading and writing on Google Cloud Storage
MIN-FU YANG created VFS-636: --- Summary: I wish that it support reading and writing on Google Cloud Storage Key: VFS-636 URL: https://issues.apache.org/jira/browse/VFS-636 Project: Commons VFS Issue Type: Wish Reporter: MIN-FU YANG Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TEXT-92) Update commons-lang dependency to version 3.6
[ https://issues.apache.org/jira/browse/TEXT-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved TEXT-92. --- Resolution: Fixed > Update commons-lang dependency to version 3.6 > - > > Key: TEXT-92 > URL: https://issues.apache.org/jira/browse/TEXT-92 > Project: Commons Text > Issue Type: Task >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher >Priority: Minor > Fix For: 1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TEXT-92) Update commons-lang dependency to version 3.6
Pascal Schumacher created TEXT-92: - Summary: Update commons-lang dependency to version 3.6 Key: TEXT-92 URL: https://issues.apache.org/jira/browse/TEXT-92 Project: Commons Text Issue Type: Task Reporter: Pascal Schumacher Assignee: Pascal Schumacher Priority: Minor Fix For: 1.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang pull request #268: .travis.yml: add oraclejdk9
Github user PascalSchumacher closed the pull request at: https://github.com/apache/commons-lang/pull/268 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #268: .travis.yml: add oraclejdk9
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/268 The build works using java 9 locally. I guess its only a few months at most until jdk 9 will be officially supported on travis, so I won't invest any more time into this for now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1340) Add IBM Java 8 CI checks for Commons Lang
[ https://issues.apache.org/jira/browse/LANG-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049676#comment-16049676 ] ASF GitHub Bot commented on LANG-1340: -- Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/271 Not (yet) ready to merge, see my comments at https://github.com/apache/commons-text/pull/45 for details. > Add IBM Java 8 CI checks for Commons Lang > - > > Key: LANG-1340 > URL: https://issues.apache.org/jira/browse/LANG-1340 > Project: Commons Lang > Issue Type: Improvement >Reporter: Amey Jadiye > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang issue #271: LANG-1340: Add ibmjdk8 support for travis-ci
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/271 Not (yet) ready to merge, see my comments at https://github.com/apache/commons-text/pull/45 for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals
[ https://issues.apache.org/jira/browse/TEXT-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated TEXT-90: -- Description: I tried to migrate a project from RandomStringUtils to RandomStringGenerator today, but I found it hard to replace methods like RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic. I believe it would ease migration from RandomStringUtils to RandomStringGenerator if CharacterPrecidates would offer more predicates. > Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic > numerals > --- > > Key: TEXT-90 > URL: https://issues.apache.org/jira/browse/TEXT-90 > Project: Commons Text > Issue Type: New Feature >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 1.2 > > > I tried to migrate a project from RandomStringUtils to RandomStringGenerator > today, but I found it hard to replace methods like > RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic. > I believe it would ease migration from RandomStringUtils to > RandomStringGenerator if CharacterPrecidates would offer more predicates. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-91) RandomStringGenerator should be able to generate a String with a random length
[ https://issues.apache.org/jira/browse/TEXT-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049628#comment-16049628 ] ASF GitHub Bot commented on TEXT-91: GitHub user PascalSchumacher opened a pull request: https://github.com/apache/commons-text/pull/51 TEXT-91: RandomStringGenerator should be able to generate a String wi… …th a random length You can merge this pull request into a Git repository by running: $ git pull https://github.com/PascalSchumacher/commons-text RandomStringGenerator_String_with_random_length Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-text/pull/51.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #51 commit 4659ea28ee66d0be4a21eeb6da927dbb65eb4d36 Author: Pascal Schumacher Date: 2017-06-14T20:34:09Z TEXT-91: RandomStringGenerator should be able to generate a String with a random length > RandomStringGenerator should be able to generate a String with a random length > -- > > Key: TEXT-91 > URL: https://issues.apache.org/jira/browse/TEXT-91 > Project: Commons Text > Issue Type: New Feature >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TEXT-91) RandomStringGenerator should be able to generate a String with a random length
[ https://issues.apache.org/jira/browse/TEXT-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated TEXT-91: -- Fix Version/s: 1.2 > RandomStringGenerator should be able to generate a String with a random length > -- > > Key: TEXT-91 > URL: https://issues.apache.org/jira/browse/TEXT-91 > Project: Commons Text > Issue Type: New Feature >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TEXT-91) RandomStringGenerator should be able to generate a String with a random length
Pascal Schumacher created TEXT-91: - Summary: RandomStringGenerator should be able to generate a String with a random length Key: TEXT-91 URL: https://issues.apache.org/jira/browse/TEXT-91 Project: Commons Text Issue Type: New Feature Reporter: Pascal Schumacher Assignee: Pascal Schumacher -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals
[ https://issues.apache.org/jira/browse/TEXT-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049602#comment-16049602 ] ASF GitHub Bot commented on TEXT-90: GitHub user PascalSchumacher opened a pull request: https://github.com/apache/commons-text/pull/50 TEXT-90: Add CharacterPredicates for ASCII letters (uppercase/lowerca… …se) and Arabic numerals You can merge this pull request into a Git repository by running: $ git pull https://github.com/PascalSchumacher/commons-text more_character_predicates Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-text/pull/50.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #50 commit fd7997ec780dd17f635086429352cd478d967f11 Author: Pascal Schumacher Date: 2017-06-14T20:04:55Z TEXT-90: Add CharacterPredicates for ASCII letters (uppercase/lowercase) and Arabic numerals > Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic > numerals > --- > > Key: TEXT-90 > URL: https://issues.apache.org/jira/browse/TEXT-90 > Project: Commons Text > Issue Type: New Feature >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals
Pascal Schumacher created TEXT-90: - Summary: Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals Key: TEXT-90 URL: https://issues.apache.org/jira/browse/TEXT-90 Project: Commons Text Issue Type: New Feature Reporter: Pascal Schumacher Assignee: Pascal Schumacher Fix For: 1.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049544#comment-16049544 ] Romain Manni-Bucau commented on JCS-178: Sounds good, here is the original commit https://github.com/apache/commons-jcs/commit/eee7e7c4b278274240ad7458da9d9073b7374415. At the beginning the list was empty but missed we just get the reference now. We can desire to keep the list copy (not the references) but [~lucianc] proposal sounds very good > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049411#comment-16049411 ] Lucian Chirita commented on JCS-178: Wouldn't it make more sense to remove the this.noWaits.add(rcnw) line? Is there a point in iterating over this.noWaits, and adding again the entries to the same list? You end up with each object appearing twice in the list. > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (JCS-176) RemoteCacheNoWaitFacade constructor throws ConcurrentModificationException
[ https://issues.apache.org/jira/browse/JCS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-176. Resolution: Duplicate Fix Version/s: jcs-2.2 > RemoteCacheNoWaitFacade constructor throws ConcurrentModificationException > -- > > Key: JCS-176 > URL: https://issues.apache.org/jira/browse/JCS-176 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-2.1 >Reporter: Dan Griffith > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade constructor throws a ConcurrentModificationException > in line 73 attempting to add to the collection it is traversing in the > enhanced for loop. > Exception is swallowed in the > org.apache.commons.jcs.engine.control.CompositeCacheConfigurator > parseAuxiliary() method which logs the statement "Could not instantiate > auxiliary cache named ...". > This prevents client from communicating changes to the remote cache. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-177) CompositeCacheManager leaks memory if CacheAccess.dipose is called
[ https://issues.apache.org/jira/browse/JCS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049366#comment-16049366 ] Thomas Vandahl commented on JCS-177: Thank you for the bug report and your patch. I however took a different approach to fix the problem using freeCache(). See commit 1798715. Please note that calling manager.release() will dispose all your caches which is probably not what you want. > CompositeCacheManager leaks memory if CacheAccess.dipose is called > -- > > Key: JCS-177 > URL: https://issues.apache.org/jira/browse/JCS-177 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.1 >Reporter: Ryan Fong >Priority: Critical > Fix For: jcs-2.2 > > Attachments: jcs-177.patch, jcs-test.zip > > > In JCS 2.1, The org.apache.commons.jcs.engine.control.CompositeCacheManager > holds onto a reference of CacheAccess in its caches map. If > CacheAccess.dispose is called, this reference is not cleaned up which results > in a memory leak. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (JCS-177) CompositeCacheManager leaks memory if CacheAccess.dipose is called
[ https://issues.apache.org/jira/browse/JCS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-177. Resolution: Fixed Assignee: Thomas Vandahl Fix Version/s: jcs-2.2 Fixed in SVN > CompositeCacheManager leaks memory if CacheAccess.dipose is called > -- > > Key: JCS-177 > URL: https://issues.apache.org/jira/browse/JCS-177 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.1 >Reporter: Ryan Fong >Assignee: Thomas Vandahl >Priority: Critical > Fix For: jcs-2.2 > > Attachments: jcs-177.patch, jcs-test.zip > > > In JCS 2.1, The org.apache.commons.jcs.engine.control.CompositeCacheManager > holds onto a reference of CacheAccess in its caches map. If > CacheAccess.dispose is called, this reference is not cleaned up which results > in a memory leak. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049333#comment-16049333 ] Romain Manni-Bucau commented on JCS-178: [~tv] you are probably right, just got a user reported the beta examples don't work anymore (examples I showed during a JUG) so checked why it was failing, found the ConcurrentModificationException and finally found the commit having refactored based on some automated tool the class to change the loop. You can see it as a partial revert so think it solved the actual issue but agree we should add some coverage here. > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl reopened JCS-178: Assignee: Thomas Vandahl (was: Romain Manni-Bucau) [~romain.manni-bucau]: Please note that your fix doesn't cure the problem, it only addresses a symptom. Also there is no test coverage for the given class. We need to look into this again. > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (JCS-175) Could not sync changes in distributed environment.
[ https://issues.apache.org/jira/browse/JCS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-175. Resolution: Invalid Assignee: Thomas Vandahl Fix Version/s: (was: jcs-2.1) jcs-2.2 Please ask such questions on the user mailing list and provide logs and error messages > Could not sync changes in distributed environment. > -- > > Key: JCS-175 > URL: https://issues.apache.org/jira/browse/JCS-175 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-2.0 > Environment: jdk1.8.0_112, jdk1.8.0_112 >Reporter: syed riazur rahman >Assignee: Thomas Vandahl >Priority: Blocker > Fix For: jcs-2.2 > > Attachments: cache.ccf, cache.ccf > > > Configured JCS in two tomcat servers running on 8080 & 8090 ports. > Server A could able to sync the changes to Sever B. > But > Server B could not able to sync the changes to Server A. > Pl, find the attached files for configuration on Server A & Server B. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TEXT-89) Add UTF-32 surrogate pairs support for WordUtils.initials()
[ https://issues.apache.org/jira/browse/TEXT-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Vinud updated TEXT-89: Description: The current implementation of WordUtils.initials() doesn't support UTF-32 . Refactor the code to provide support using UTF-16 surrogate pairs . The proposed improvement should provide support to characters outside BMP. (was: The current implementation of WordUtils.initials() doesn't support UTF-32 . Refactor the code to provide native support for surrogate pairs . The proposed improvement should provide support to characters outside BMP.) > Add UTF-32 surrogate pairs support for WordUtils.initials() > --- > > Key: TEXT-89 > URL: https://issues.apache.org/jira/browse/TEXT-89 > Project: Commons Text > Issue Type: Improvement >Reporter: Arun Vinud >Priority: Minor > > The current implementation of WordUtils.initials() doesn't support UTF-32 . > Refactor the code to provide support using UTF-16 surrogate pairs . The > proposed improvement should provide support to characters outside BMP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NUMBERS-43) Remove "round(float)" methods?
[
https://issues.apache.org/jira/browse/NUMBERS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049054#comment-16049054
]
Bruno P. Kinoshita commented on NUMBERS-43:
---
>Here I suggest to remove a utility which has no identified usage (cf. "Commons
>Math" codebase).
Ack
>Are the float methods defined in Precision helpful tools for those
>manipulations? In the affirmative, we must keep them. If not, why bother (in
>v1.0)?
Makes sense.
>What about
>
>Perform the crusade (limited to the yet unreleased "Numbers"...)
>Make a note about it in the "ANNOUNCE" message and in the "RELEASE NOTES"
>
> Then, depending on the feedback, we can go forward with what the user
> community really needs/wants.
In that case I'm +0 for removing it :-) should any user with a valid argument
suggests adding the method, we can just proceed and add it then.
> Remove "round(float)" methods?
> --
>
> Key: NUMBERS-43
> URL: https://issues.apache.org/jira/browse/NUMBERS-43
> Project: Commons Numbers
> Issue Type: Wish
>Reporter: Gilles
> Labels: api, float
> Fix For: 1.0
>
>
> In class {{Precision}}, there are methods for rounding {{float}} values, e.g.
> {code:java}
> public static float round(float x, int scale, int roundingMethod) { /* ... */
> }
> {code}
> Is there any use for supporting specific handling of floats (in these times
> where memory is not a scarce resources anymore)?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NUMBERS-43) Remove "round(float)" methods?
[
https://issues.apache.org/jira/browse/NUMBERS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049050#comment-16049050
]
Gilles commented on NUMBERS-43:
---
This issue came about because FindBugs signals a problem in the
{{roundUnscaled}} method.
Amey wanted to implement FindBugs' suggestion, although a comment says that the
statement is _intentional_.
I don't have the time to try and understand (with additional unit tests and
benchmarks) whether this is OK or not, even less to figure out where the method
would still be required/useful.
My proposal is to remove anything and everything that creates (or will create)
trouble for no reason.
If necessary, this page is tracking history and the code can be recovered from
the source repository, to be added in 1.x if actual use-cases appear.
Bruno, the discussion you refer to is interesting but beside the point: there,
they discuss something (the {{float}} type) *used* by libraries, that obviously
wouldn't work anymore if it were removed from the language. Here I suggest to
remove a utility which has *no* identified usage (cf. "Commons Math" codebase).
Avoiding creating {{double}} could be a valid argument; but does it mean that
we intend to actively support {{float}} manipulations, e.g. have classes like
{{Complex}} provide {{float}} accuracy? I don't think so; so we'd have a few
methods which we won't ever remove, even though nobody will ever use them. :(
Passing data to and from a GPU is an interesting use-case (IIRC, Eric Barnhill
intended to provide some support in the {{o.a.c.numbers.complex}} package). Are
the {{float}} methods defined in {{Precision}} helpful tools for those
manipulations? In the affirmative, we must keep them. If not, why bother (in
v1.0)?
What about
# Perform the crusade (limited to the yet unreleased "Numbers"...) ;)
# Make a note about it in the "ANNOUNCE" message and in the "RELEASE NOTES"
?
Then, depending on the feedback, we can go forward with what the user community
really needs/wants.
> Remove "round(float)" methods?
> --
>
> Key: NUMBERS-43
> URL: https://issues.apache.org/jira/browse/NUMBERS-43
> Project: Commons Numbers
> Issue Type: Wish
>Reporter: Gilles
> Labels: api, float
> Fix For: 1.0
>
>
> In class {{Precision}}, there are methods for rounding {{float}} values, e.g.
> {code:java}
> public static float round(float x, int scale, int roundingMethod) { /* ... */
> }
> {code}
> Is there any use for supporting specific handling of floats (in these times
> where memory is not a scarce resources anymore)?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLI-277) Add generics to TypeHandler
[ https://issues.apache.org/jira/browse/CLI-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048998#comment-16048998 ] ASF GitHub Bot commented on CLI-277: Github user kinow commented on the issue: https://github.com/apache/commons-cli/pull/13 +1 code in pull request looks good, tests too. But when I checked out the code to read it on Eclipse, I thought the class Javadoc a bit confusing. ``` * This is a temporary implementation. TypeHandler will handle the * pluggableness of OptionTypes and it will direct all of these types * of conversion functionalities to ConvertUtils component in Commons * already. BeanUtils I think. ``` Haven't checked the git log, but after reading it, it sounds like this class is a temporary solution until another class is ready to be used as a replacement? I wonder if there is a class in some other component perhaps that we could use and maybe replace it? Or we can just update this javadoc later. > Add generics to TypeHandler > --- > > Key: CLI-277 > URL: https://issues.apache.org/jira/browse/CLI-277 > Project: Commons CLI > Issue Type: Improvement >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > TypeHandler currently works on Object. Since we pass the class class of the > return value, we can add generics. This way we don't need to cast the > returned value explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLI-277) Add generics to TypeHandler
[ https://issues.apache.org/jira/browse/CLI-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048997#comment-16048997 ] ASF GitHub Bot commented on CLI-277: Github user kinow commented on the issue: https://github.com/apache/commons-cli/pull/13 +1 code in pull request looks good, tests too. But when I checked out the code to read it on Eclipse, I thought the class Javadoc a bit confusing. ``` * This is a temporary implementation. TypeHandler will handle the * pluggableness of OptionTypes and it will direct all of these types * of conversion functionalities to ConvertUtils component in Commons * already. BeanUtils I think. ``` Haven't checked the git log, but after reading it, it sounds like this class is a temporary solution until another class is ready to be used as a replacement? I wonder if there is a class in some other component perhaps that we could use and maybe replace it? Or we can just update this javadoc later. > Add generics to TypeHandler > --- > > Key: CLI-277 > URL: https://issues.apache.org/jira/browse/CLI-277 > Project: Commons CLI > Issue Type: Improvement >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > TypeHandler currently works on Object. Since we pass the class class of the > return value, we can add generics. This way we don't need to cast the > returned value explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048980#comment-16048980
]
Gilles commented on TEXT-88:
bq. reply appropriately
When a library method gets {{null}}, it cannot know whether it was intentional
or not.
I'd certainly prefer being warned that something is shaky (through NPE) rather
than the program continuing a computation that is not what I intended.
The "feature" may be fine at the _application_ level (where context in better
known).
bq. mentioning behavior in Javadoc of each method is good enough to tell users
how it will work.
It will not save them from a programming error.
Why is it not sufficient to have syntactic sugar:
{code}
WordUtils.capitalizeFully(string)
{code}
that is documented to behave like
{code}
WordUtils.capitalizeFully(string, delim)
{code}
where "delim" is e.g. whitespace?
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048828#comment-16048828
]
Amey Jadiye edited comment on TEXT-88 at 6/14/17 9:26 AM:
--
[~erans] the behavior you are looking as bug , I see it as feature ;-), IMO
rather throwing NPE we should handle situation and reply appropriately and
that's how many method works in Commons Text , mentioning behavior in Javadoc
of each method is good enough to tell users how it will work.
was (Author: ameyjadiye):
[~gilles] the behavior you are looking as bug , I see it as feature ;-), IMO
rather throwing NPE we should handle situation and reply appropriately and
that's how many method works in Commons Text , mentioning behavior in Javadoc
of each method is good enough to tell users how it will work.
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLI-277) Add generics to TypeHandler
[ https://issues.apache.org/jira/browse/CLI-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048863#comment-16048863 ] ASF GitHub Bot commented on CLI-277: Github user coveralls commented on the issue: https://github.com/apache/commons-cli/pull/13 [](https://:/builds/11962867) Coverage remained the same at 96.244% when pulling **c17d0ff553fd34e2e53e0446083ee284ee97f6cb on britter:CLI-277** into **0b453953fa5f55cf2e8fd034d4d55972deb7647a on apache:master**. > Add generics to TypeHandler > --- > > Key: CLI-277 > URL: https://issues.apache.org/jira/browse/CLI-277 > Project: Commons CLI > Issue Type: Improvement >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > TypeHandler currently works on Object. Since we pass the class class of the > return value, we can add generics. This way we don't need to cast the > returned value explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLI-277) Add generics to TypeHandler
[ https://issues.apache.org/jira/browse/CLI-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048862#comment-16048862 ] ASF GitHub Bot commented on CLI-277: Github user coveralls commented on the issue: https://github.com/apache/commons-cli/pull/13 [](https://:/builds/11962867) Coverage remained the same at 96.244% when pulling **c17d0ff553fd34e2e53e0446083ee284ee97f6cb on britter:CLI-277** into **0b453953fa5f55cf2e8fd034d4d55972deb7647a on apache:master**. > Add generics to TypeHandler > --- > > Key: CLI-277 > URL: https://issues.apache.org/jira/browse/CLI-277 > Project: Commons CLI > Issue Type: Improvement >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > TypeHandler currently works on Object. Since we pass the class class of the > return value, we can add generics. This way we don't need to cast the > returned value explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLI-277) Add generics to TypeHandler
[ https://issues.apache.org/jira/browse/CLI-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048854#comment-16048854 ] ASF GitHub Bot commented on CLI-277: GitHub user britter opened a pull request: https://github.com/apache/commons-cli/pull/13 CLI-277: Add generics to TypeHandler You can merge this pull request into a Git repository by running: $ git pull https://github.com/britter/commons-cli CLI-277 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-cli/pull/13.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #13 commit c17d0ff553fd34e2e53e0446083ee284ee97f6cb Author: Benedikt Ritter Date: 2017-06-14T08:25:32Z CLI-277: Add generics to TypeHandler > Add generics to TypeHandler > --- > > Key: CLI-277 > URL: https://issues.apache.org/jira/browse/CLI-277 > Project: Commons CLI > Issue Type: Improvement >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > TypeHandler currently works on Object. Since we pass the class class of the > return value, we can add generics. This way we don't need to cast the > returned value explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLI-277) Add generics to TypeHandler
[ https://issues.apache.org/jira/browse/CLI-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048853#comment-16048853 ] ASF GitHub Bot commented on CLI-277: GitHub user britter opened a pull request: https://github.com/apache/commons-cli/pull/13 CLI-277: Add generics to TypeHandler You can merge this pull request into a Git repository by running: $ git pull https://github.com/britter/commons-cli CLI-277 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-cli/pull/13.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #13 commit c17d0ff553fd34e2e53e0446083ee284ee97f6cb Author: Benedikt Ritter Date: 2017-06-14T08:25:32Z CLI-277: Add generics to TypeHandler > Add generics to TypeHandler > --- > > Key: CLI-277 > URL: https://issues.apache.org/jira/browse/CLI-277 > Project: Commons CLI > Issue Type: Improvement >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > TypeHandler currently works on Object. Since we pass the class class of the > return value, we can add generics. This way we don't need to cast the > returned value explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048828#comment-16048828
]
Amey Jadiye commented on TEXT-88:
-
[~gilles] the behavior you are looking as bug , I see it as feature ;-), IMO
rather throwing NPE we should handle situation and reply appropriately and
that's how many method works in Commons Text , mentioning behavior in Javadoc
of each method is good enough to tell users how it will work.
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IO-540) Ambiguous parameter in AbtractFileFilter.accept(File,String).
[ https://issues.apache.org/jira/browse/IO-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikhil Shinde updated IO-540: - Description: Although we are required to override the AbstractFilteFilter.accept() method to avoid Infinite loop, the arguments in current implementation seems ambiguous. File.getParentFile() is passed as argument to FilenameFilter.accept(File,String) overridden method. File.getParentFile() returns null if parent dir is not known(occurs mostly when using relative path). Java doc for FilenameFilter.accept() does not mention of allowing null value for File parameter. It would be better to change this argument that guarantee non-null value. No exception occurs at runtime, as overridden method is to be used to avoid Infinite looping. was: Although we are required to override the AbstractFilteFilter.accept() method to avoid Infinite loop, the arguments in current implementation seems ambiguous. File.getParentFile() is passed as argument to FilenameFilter.accept(File,String) overridden method. File.getParentFile() returns null if parent dir is not known(occurs mostly when using relative path). Java doc for FilenameFilter.accept() does not mention of allowing null value for File parameter. It would be better to make change in other arguments passed in accept(File,String). No exception occurs at runtime, as overridden method is to be used to avoid Infinite looping. > Ambiguous parameter in AbtractFileFilter.accept(File,String). > -- > > Key: IO-540 > URL: https://issues.apache.org/jira/browse/IO-540 > Project: Commons IO > Issue Type: Improvement > Components: Filters >Reporter: Nikhil Shinde >Priority: Minor > > Although we are required to override the AbstractFilteFilter.accept() method > to avoid Infinite loop, the arguments in current implementation seems > ambiguous. File.getParentFile() is passed as argument to > FilenameFilter.accept(File,String) overridden method. File.getParentFile() > returns null if parent dir is not known(occurs mostly when using relative > path). Java doc for FilenameFilter.accept() does not mention of allowing null > value for File parameter. It would be better to change this argument that > guarantee non-null value. > No exception occurs at runtime, as overridden method is to be used to avoid > Infinite looping. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CLI-277) Add generics to TypeHandler
[ https://issues.apache.org/jira/browse/CLI-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated CLI-277: Assignee: Benedikt Ritter > Add generics to TypeHandler > --- > > Key: CLI-277 > URL: https://issues.apache.org/jira/browse/CLI-277 > Project: Commons CLI > Issue Type: Improvement >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > > TypeHandler currently works on Object. Since we pass the class class of the > return value, we can add generics. This way we don't need to cast the > returned value explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLI-277) Add generics to TypeHandler
Benedikt Ritter created CLI-277: --- Summary: Add generics to TypeHandler Key: CLI-277 URL: https://issues.apache.org/jira/browse/CLI-277 Project: Commons CLI Issue Type: Improvement Reporter: Benedikt Ritter TypeHandler currently works on Object. Since we pass the class class of the return value, we can add generics. This way we don't need to cast the returned value explicitly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing
[
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved CLI-274.
-
Resolution: Fixed
Fix Version/s: 1.5
Merged in 0b45395.
Thank you!
> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Reporter: Béla Schaum
>Assignee: Benedikt Ritter
>Priority: Minor
> Fix For: 1.5
>
>
> When the user pass option type FileInputStream.class, I think the expected
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); //
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing
[
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048820#comment-16048820
]
ASF GitHub Bot commented on CLI-274:
Github user asfgit closed the pull request at:
https://github.com/apache/commons-cli/pull/12
> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Reporter: Béla Schaum
>Assignee: Benedikt Ritter
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); //
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing
[
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048819#comment-16048819
]
ASF GitHub Bot commented on CLI-274:
Github user asfgit closed the pull request at:
https://github.com/apache/commons-cli/pull/12
> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Reporter: Béla Schaum
>Assignee: Benedikt Ritter
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); //
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing
[
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated CLI-274:
Assignee: Benedikt Ritter
> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Reporter: Béla Schaum
>Assignee: Benedikt Ritter
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); //
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NUMBERS-43) Remove "round(float)" methods?
[
https://issues.apache.org/jira/browse/NUMBERS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048795#comment-16048795
]
Emmanuel Bourg commented on NUMBERS-43:
---
I also think we should keep the method, we aren't on a crusade to deprecate
floats in all our components anyway. floats are still there and we don't know
how people are using them.
> Remove "round(float)" methods?
> --
>
> Key: NUMBERS-43
> URL: https://issues.apache.org/jira/browse/NUMBERS-43
> Project: Commons Numbers
> Issue Type: Wish
>Reporter: Gilles
> Labels: api, float
> Fix For: 1.0
>
>
> In class {{Precision}}, there are methods for rounding {{float}} values, e.g.
> {code:java}
> public static float round(float x, int scale, int roundingMethod) { /* ... */
> }
> {code}
> Is there any use for supporting specific handling of floats (in these times
> where memory is not a scarce resources anymore)?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-89) Add UTF-32 surrogate pairs support for WordUtils.initials()
[ https://issues.apache.org/jira/browse/TEXT-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048779#comment-16048779 ] ASF GitHub Bot commented on TEXT-89: Github user arunvinudss commented on the issue: https://github.com/apache/commons-text/pull/49 @ecki I agree and thats the best we can do for now to support UTF-32 . Thanks for the input 👍 > Add UTF-32 surrogate pairs support for WordUtils.initials() > --- > > Key: TEXT-89 > URL: https://issues.apache.org/jira/browse/TEXT-89 > Project: Commons Text > Issue Type: Improvement >Reporter: Arun Vinud >Priority: Minor > > The current implementation of WordUtils.initials() doesn't support UTF-32 . > Refactor the code to provide native support for surrogate pairs . The > proposed improvement should provide support to characters outside BMP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
