[jira] [Commented] (MATH-1387) Travis CI does not work in master branch

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519939#comment-15519939
 ] 

Rob Tompkins commented on MATH-1387:


Hm...curious. That opens an interesting unit testing problem to solve 
generally: how to write a deterministic unit test for something that 
necessarily is non-deterministic in nature. That's a really good one that'll 
probably have me thinking all this week.

Regardless, on the other build failure it seems that it could be failing 
because of some jacoco/surefire incompatibility, but I haven't pin pointed 
anything there...planning on continuing to chip away at it.

> Travis CI does not work in master branch
> 
>
> Key: MATH-1387
> URL: https://issues.apache.org/jira/browse/MATH-1387
> Project: Commons Math
>  Issue Type: Bug
> Environment: github
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The travis-ci & coveralls build do not work in the master branch



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IO-499) FilenameUtils.directoryContains(String, String) gives false positive when two directories exist with equal prefixes

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IO-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519730#comment-15519730
 ] 

ASF GitHub Bot commented on IO-499:
---

GitHub user cagdasyelen opened a pull request:

https://github.com/apache/commons-io/pull/20

[IO-499] FilenameUtils.directoryContains false positive issue 

IO-499 bug has been fixed. 

The old version was looking at if the child canonical path string starts 
with the parent's. 
However, it fails in the case of:

.../top/foo
.../top/foo2/b.txt

since the directory path of b.txt starts with the same directory path with 
the one above even though the second one is a different directory(foo2). This 
issue is resolved by comparing the path strings of foo and foo2. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cagdasyelen/commons-io io499-fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/20.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 #20


commit fd95ccde6310bfee7314744d879c597882cb3381
Author: Cagdas Yelen 
Date:   2016-09-24T22:21:37Z

[IO-499] FilenameUtils.directoryContains false positive issue is resolved




> FilenameUtils.directoryContains(String, String) gives false positive when two 
> directories exist with equal prefixes
> ---
>
> Key: IO-499
> URL: https://issues.apache.org/jira/browse/IO-499
> Project: Commons IO
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Federico Bonelli
>Priority: Minor
>
> In a folder layout as such:
> {code}
> /foo/a.txt
> /foo2/b.txt
> {code}
> The result of invoking directoryContains is wrong:
> {code}
> FilenameUtils.directoryContains("/foo", "/foo2/b.txt"); // returns true
> {code}
> even if "/foo" and "/foo2/b.txt" are the canonical paths, they start with the 
> same characters, and the current implementation of the method fails.
> As workaround we are currently appending a path separator '/' to the first 
> argument.
> It is noteworthy that the current implementation of 
> FileUtils.directoryContains() reveals this issue because it uses the 
> File.getCanonicalPath() to obtain the String paths of "/foo" and 
> "/foo2/b.txt".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CSV-196) Store the info of whether a field is enclosed by quotes

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519691#comment-15519691
 ] 

Gary Gregory commented on CSV-196:
--

The HEAD of Git master.

Gary

> Store the info of whether a field is enclosed by quotes
> ---
>
> Key: CSV-196
> URL: https://issues.apache.org/jira/browse/CSV-196
> Project: Commons CSV
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.4
>Reporter: Matt Sun
>  Labels: easyfix, features, patch
> Fix For: Patch Needed
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It will be good to have CSVParser class to store the info of whether a field 
> was enclosed by quotes in the original source file.
> For example, for this data sample:
> A, B, C
> a1, "b1", c1
> CSVParser gives us record a1, b1, c1, which is helpful because it parsed 
> double quotes, but we also lost the information of original data at the same 
> time. We can't tell from the CSVRecord returned whether the original data is 
> enclosed by double quotes or not.
> In our use case, we are integrating Apache Hadoop APIs with Commons CSV.  CSV 
> is one kind of input of Hadoop Jobs, which should support splitting input 
> data. To accurately split a CSV file into pieces, we need to count the bytes 
> of  data CSVParser actually read. CSVParser doesn't have accurate information 
> of whether a field was enclosed by quotes, neither does it store raw data of 
> the original source. Downstream users of commons CSVParser is not able to get 
> those info.
> To suggest a fix: Extend the token/CSVRecord to have a boolean field 
> indicating whether the column was enclosed by quotes. While Lexer is doing 
> getNextToken, set the flag if a field is encapsulated and successfully parsed.
> I find another issue reported with similar request, but it was marked as 
> resolved: [CSV91] 
> https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IO-483) getPrefixLength return -1 if unix file contains colon

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IO-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519519#comment-15519519
 ] 

ASF GitHub Bot commented on IO-483:
---

GitHub user marko-vasic opened a pull request:

https://github.com/apache/commons-io/pull/19

[IO-483] FilenameUtils.getPrefixLength fix for unix files/folders starting 
with colon

FilenameUtils.getPrefixLength now works correctly for unix files/folder 
that are in the root folder and start with colons

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/marko-vasic/commons-io master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/19.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 #19


commit a7bd568249f9ec20b69b2a700da6a0648e93a842
Author: Marko Vasic 
Date:   2016-09-24T19:32:50Z

[IO-483] FilenameUtils.getPrefixLength now works correctly for unix 
files/folder that are in the root folder and start with colons




> getPrefixLength return -1 if unix file contains colon
> -
>
> Key: IO-483
> URL: https://issues.apache.org/jira/browse/IO-483
> Project: Commons IO
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.4
>Reporter: Tristan Lins
>
> A simple
> {code:java}
> int prefixLength = FilenameUtils.getPrefixLength("/:foo/bar");
> {code}
> return {{-1}}, but {{0}} was expected. The path is absolutely valid for unix 
> systems.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BEANUTILS-497) Fix javadoc doclint errors

[Stian Soiland-Reyes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stian Soiland-Reyes updated BEANUTILS-497:
--
Fix Version/s: 1.9.3

> Fix javadoc doclint errors
> --
>
> Key: BEANUTILS-497
> URL: https://issues.apache.org/jira/browse/BEANUTILS-497
> Project: Commons BeanUtils
>  Issue Type: Task
>Affects Versions: 1.9.3
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
>
> Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) - 
> which breaks {{mvn site}} there.
> Try with:
> {code}
> mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
> {code}
> (or if you are brave - {{-Xdoclint:all}} )
> and get various errors and warnings like:
> {code}
> [ERROR] Exit code: 1 - 
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
>  error: bad use of '>'
> [ERROR] * register your own String --> Object conversions for any given Java 
> class.
> [ERROR] ^
> [ERROR] 
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
>  warning: empty  tag
> [ERROR] * 
> [ERROR] ^
> {code}
> Most of these relate to wrong use of HTML, which we should fix (it affects 
> the html we put on our site).
> I notice that beanutils has a large use of 
> {code}
> DynaClass
> {code}
> where perhaps I would have expected
> {code}
> {@link DynaClass}
> {code}
> -- but if you fix those - make sure that you also get the full classname for 
> classes in a different package that are not {{import}}ed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BEANUTILS-497) Fix javadoc doclint errors

[Stian Soiland-Reyes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/BEANUTILS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stian Soiland-Reyes updated BEANUTILS-497:
--
Fix Version/s: (was: 1.9.3)

> Fix javadoc doclint errors
> --
>
> Key: BEANUTILS-497
> URL: https://issues.apache.org/jira/browse/BEANUTILS-497
> Project: Commons BeanUtils
>  Issue Type: Task
>Affects Versions: 1.9.3
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
>
> Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) - 
> which breaks {{mvn site}} there.
> Try with:
> {code}
> mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
> {code}
> (or if you are brave - {{-Xdoclint:all}} )
> and get various errors and warnings like:
> {code}
> [ERROR] Exit code: 1 - 
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
>  error: bad use of '>'
> [ERROR] * register your own String --> Object conversions for any given Java 
> class.
> [ERROR] ^
> [ERROR] 
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
>  warning: empty  tag
> [ERROR] * 
> [ERROR] ^
> {code}
> Most of these relate to wrong use of HTML, which we should fix (it affects 
> the html we put on our site).
> I notice that beanutils has a large use of 
> {code}
> DynaClass
> {code}
> where perhaps I would have expected
> {code}
> {@link DynaClass}
> {code}
> -- but if you fix those - make sure that you also get the full classname for 
> classes in a different package that are not {{import}}ed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CSV-196) Store the info of whether a field is enclosed by quotes

[Matt Sun (JIRA)]

[ 
https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519443#comment-15519443
 ] 

Matt Sun commented on CSV-196:
--

Sure, I can do. Which version should the patch based on?

> Store the info of whether a field is enclosed by quotes
> ---
>
> Key: CSV-196
> URL: https://issues.apache.org/jira/browse/CSV-196
> Project: Commons CSV
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.4
>Reporter: Matt Sun
>  Labels: easyfix, features, patch
> Fix For: Patch Needed
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It will be good to have CSVParser class to store the info of whether a field 
> was enclosed by quotes in the original source file.
> For example, for this data sample:
> A, B, C
> a1, "b1", c1
> CSVParser gives us record a1, b1, c1, which is helpful because it parsed 
> double quotes, but we also lost the information of original data at the same 
> time. We can't tell from the CSVRecord returned whether the original data is 
> enclosed by double quotes or not.
> In our use case, we are integrating Apache Hadoop APIs with Commons CSV.  CSV 
> is one kind of input of Hadoop Jobs, which should support splitting input 
> data. To accurately split a CSV file into pieces, we need to count the bytes 
> of  data CSVParser actually read. CSVParser doesn't have accurate information 
> of whether a field was enclosed by quotes, neither does it store raw data of 
> the original source. Downstream users of commons CSVParser is not able to get 
> those info.
> To suggest a fix: Extend the token/CSVRecord to have a boolean field 
> indicating whether the column was enclosed by quotes. While Lexer is doing 
> getNextToken, set the flag if a field is encapsulated and successfully parsed.
> I find another issue reported with similar request, but it was marked as 
> resolved: [CSV91] 
> https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CSV-197) CSVParser doesn't close the underlying handle after iteration

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/CSV-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519430#comment-15519430
 ] 

Gary Gregory commented on CSV-197:
--

The parser implements close() which calls close() on the lexer which closes() 
the reader.

So all you have to do is manage the parser in a try-with-resources block:

{code:java}
  try (final CSVParser parser = CSVParser.parse(...)) {
  ...
  }
{code}



> CSVParser doesn't close the underlying handle after iteration
> -
>
> Key: CSV-197
> URL: https://issues.apache.org/jira/browse/CSV-197
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Parser
>Reporter: Prateek Rungta
>Priority: Minor
> Fix For: Patch Needed, Discussion, 1.4.1
>
>
> The following code leaks file handles:
> {code}
> CSVParser parser = // setup parser
> for (CSVRecord rec: parser) {
> }
> // leak
> {code}
> I'd expect the underlying iterator to close() if it's finished iterating. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CSV-197) CSVParser doesn't close the underlying handle after iteration

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/CSV-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519430#comment-15519430
 ] 

Gary Gregory edited comment on CSV-197 at 9/24/16 6:31 PM:
---

The parser implements close() which calls close() on the lexer which closes() 
the reader.

So all you have to do is manage the parser in a try-with-resources block:

{code:java}
  try (final CSVParser parser = CSVParser.parse(...)) {
...
  }
{code}




was (Author: garydgregory):
The parser implements close() which calls close() on the lexer which closes() 
the reader.

So all you have to do is manage the parser in a try-with-resources block:

{code:java}
  try (final CSVParser parser = CSVParser.parse(...)) {
  ...
  }
{code}



> CSVParser doesn't close the underlying handle after iteration
> -
>
> Key: CSV-197
> URL: https://issues.apache.org/jira/browse/CSV-197
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Parser
>Reporter: Prateek Rungta
>Priority: Minor
> Fix For: Patch Needed, Discussion, 1.4.1
>
>
> The following code leaks file handles:
> {code}
> CSVParser parser = // setup parser
> for (CSVRecord rec: parser) {
> }
> // leak
> {code}
> I'd expect the underlying iterator to close() if it's finished iterating. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #192: Lang 1255: Add DateUtils.toCalendar(Date, TimeZone)...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/192
  

[![Coverage 
Status](https://coveralls.io/builds/8035489/badge)](https://coveralls.io/builds/8035489)

Coverage decreased (-0.0006%) to 93.528% when pulling 
**d9a2c69a9d1db6072e1d7b7ea4fcbd5c15d20b5d on kaiyuanw:lang-1255** into 
**db6f7c1d74ba64211221a69cfa9fe7171a9199e8 on apache:master**.



---
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 #192: Lang 1255: Add DateUtils.toCalendar(Date, TimeZone)...

[kaiyuanw]

Github user kaiyuanw commented on the issue:

https://github.com/apache/commons-lang/pull/192
  
@britter Your comments are handled and please check if it is good now.  
Thank you.


---
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 pull request #192: Lang 1255: Add DateUtils.toCalendar(Date, Ti...

[kaiyuanw]

Github user kaiyuanw commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/192#discussion_r80362430
  
--- Diff: src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java ---
@@ -693,6 +693,43 @@ public void testToCalendar() {
 // expected
 }
 }
+
+
//---
+@Test
+public void testToCalendarWithDate() {
+assertEquals("Convert Date and TimeZone to a Calendar, but failed 
to get the Date back", date1, DateUtils.toCalendar(date1, zone).getTime());
+try {
+DateUtils.toCalendar(null, zone);
+fail("Expected NullPointerException to be thrown");
+} catch(final NullPointerException npe) {
+// expected
+}
+}
+
+
//---
+@Test
+public void testToCalendarWithTimeZone() {
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the TimeZone back", zone, DateUtils.toCalendar(date1, 
zone).getTimeZone());
+try {
+DateUtils.toCalendar(date1, null);
+fail("Expected NullPointerException to be thrown");
+} catch(final NullPointerException npe) {
+// expected
+}
+}
+
+  //---
+@Test
+public void testToCalendarWithDateAndTimeZone() {
+try {
+   Calendar c = DateUtils.toCalendar(date2, defaultZone);
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the Date back", date2, c.getTime());
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the TimeZone back", defaultZone, c.getTimeZone());
+   // expected
+} catch(final NullPointerException npe) {
+   fail("Expected NullPointerException to be thrown");
--- End diff --

That's a typo.  Fixed.  Please check.


---
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 pull request #192: Lang 1255: Add DateUtils.toCalendar(Date, Ti...

[kaiyuanw]

Github user kaiyuanw commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/192#discussion_r80362427
  
--- Diff: src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java ---
@@ -693,6 +693,43 @@ public void testToCalendar() {
 // expected
 }
 }
+
+
//---
+@Test
+public void testToCalendarWithDate() {
+assertEquals("Convert Date and TimeZone to a Calendar, but failed 
to get the Date back", date1, DateUtils.toCalendar(date1, zone).getTime());
+try {
+DateUtils.toCalendar(null, zone);
+fail("Expected NullPointerException to be thrown");
+} catch(final NullPointerException npe) {
+// expected
+}
+}
+
+
//---
+@Test
+public void testToCalendarWithTimeZone() {
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the TimeZone back", zone, DateUtils.toCalendar(date1, 
zone).getTimeZone());
+try {
+DateUtils.toCalendar(date1, null);
+fail("Expected NullPointerException to be thrown");
+} catch(final NullPointerException npe) {
+// expected
+}
+}
+
+  //---
+@Test
+public void testToCalendarWithDateAndTimeZone() {
+try {
+   Calendar c = DateUtils.toCalendar(date2, defaultZone);
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the Date back", date2, c.getTime());
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the TimeZone back", defaultZone, c.getTimeZone());
--- End diff --

Good point.  Fixed.  Please check.


---
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 pull request #192: Lang 1255: Add DateUtils.toCalendar(Date, Ti...

[kaiyuanw]

Github user kaiyuanw commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/192#discussion_r80362422
  
--- Diff: src/main/java/org/apache/commons/lang3/time/DateUtils.java ---
@@ -668,6 +668,19 @@ public static Calendar toCalendar(final Date date) {
 
 
//---
 /**
+ * Converts a {@code Date} of a given {@code TimeZone} into a {@code 
Calendar}
+ * @param date the date to convert to a Calendar
+ * @param timeZone the time zone of the @{code date}
+ * @return
--- End diff --

Fixed.  Please check.


---
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] (MATH-1387) Travis CI does not work in master branch

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519101#comment-15519101
 ] 

Gilles commented on MATH-1387:
--

bq.  I would think we would want the build to be deterministic.

>From [Javadoc for {{SecureRandom}} | 
>https://docs.oracle.com/javase/7/docs/api/java/security/SecureRandom.html]: 
>"SecureRandom must produce non-deterministic output."

A way to avoid some of the build failures is to use the custom "RetryRunner".
See e.g. 
{{src/test/java/org/apache/commons/math4/ml/neuralnet/sofm/KohonenTrainingTaskTest.java}}


> Travis CI does not work in master branch
> 
>
> Key: MATH-1387
> URL: https://issues.apache.org/jira/browse/MATH-1387
> Project: Commons Math
>  Issue Type: Bug
> Environment: github
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The travis-ci & coveralls build do not work in the master branch



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #193: Add isAnyNotEmpty() and isAnyNotBlank() to StringUt...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/193
  

[![Coverage 
Status](https://coveralls.io/builds/8035022/badge)](https://coveralls.io/builds/8035022)

Coverage increased (+0.02%) to 93.546% when pulling 
**03ba8cbe17128556539598112eb8d1dfbe665f1b on 
ptemplier:stringutils-new-methods** into 
**cac7a60abf0a4451a5c80ef57343a14ea1ba443f on apache:master**.



---
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 #193: Add isAnyNotEmpty() and isAnyNotBlank() to StringUt...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/193
  

[![Coverage 
Status](https://coveralls.io/builds/8035004/badge)](https://coveralls.io/builds/8035004)

Coverage increased (+0.03%) to 93.557% when pulling 
**96810e2fd2d2558989f006e35cb0cf0c3ac127ce on 
ptemplier:stringutils-new-methods** into 
**db6f7c1d74ba64211221a69cfa9fe7171a9199e8 on apache:master**.



---
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 #193: Add isAnyNotEmpty() and isAnyNotBlank() to StringUt...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/193
  

[![Coverage 
Status](https://coveralls.io/builds/8035004/badge)](https://coveralls.io/builds/8035004)

Coverage increased (+0.03%) to 93.557% when pulling 
**96810e2fd2d2558989f006e35cb0cf0c3ac127ce on 
ptemplier:stringutils-new-methods** into 
**db6f7c1d74ba64211221a69cfa9fe7171a9199e8 on apache:master**.



---
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] (MATH-1387) Travis CI does not work in master branch

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15519006#comment-15519006
 ] 

Rob Tompkins commented on MATH-1387:


It's beginning to feel like we're running up against either thread count or 
memory utilization and the JVM is somehow crashing...I'm currently playing 
around with thread count in my fork of master:

https://travis-ci.org/chtompki/commons-math/builds

> Travis CI does not work in master branch
> 
>
> Key: MATH-1387
> URL: https://issues.apache.org/jira/browse/MATH-1387
> Project: Commons Math
>  Issue Type: Bug
> Environment: github
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The travis-ci & coveralls build do not work in the master branch



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MATH-1387) Travis CI does not work in master branch

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518986#comment-15518986
 ] 

Rob Tompkins commented on MATH-1387:


Him...that makes me feel a little uneasy. I would think we would want the build 
to be deterministic.

> Travis CI does not work in master branch
> 
>
> Key: MATH-1387
> URL: https://issues.apache.org/jira/browse/MATH-1387
> Project: Commons Math
>  Issue Type: Bug
> Environment: github
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The travis-ci & coveralls build do not work in the master branch



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1269) Wrong name or result of StringUtils::getJaroWinklerDistance

[Benedikt Ritter (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518833#comment-15518833
 ] 

Benedikt Ritter commented on LANG-1269:
---

This probably also affects Commons Text

> Wrong name or result of StringUtils::getJaroWinklerDistance
> ---
>
> Key: LANG-1269
> URL: https://issues.apache.org/jira/browse/LANG-1269
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.3, 3.4
>Reporter: Jan Martin Keil
>Priority: Minor
>
> The name of the method StringUtils::getJaroWinklerDistance is misleading.
> Currently for equal strings {{1}} is returned, for completely different 
> strings {{0}} is returned. That is a measure of similarity, not of a 
> distance. A distance must be {{0}} for equal strings. I read on the issues 
> LANG-591 and LANG-944, that it was decided to have a similar name to 
> StringUtils::getLevenshteinDistance, but that requires also the change of the 
> methods result.
> Could you please (1) rename the method to 
> StringUtils::getJaroWinklerSimilarity or (2) change the method to return {{1 
> - currentResult}}?
> First option has the disadvantage to lose the similar naming of the similar 
> methods, second option implies the risk to unnoticed introduce bugs in 
> depending code. So I think it is preferable to use the first option.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #193: Add isAnyNotEmpty() and isAnyNotBlank() to S...

[ptemplier]

Github user ptemplier commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/193#discussion_r80358287
  
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -258,6 +258,35 @@ public static boolean isAnyEmpty(final CharSequence... 
css) {
 }
 
 /**
+ * Checks if any one of the CharSequences are not empty ("") or 
null.
+ *
+ * 
+ * StringUtils.isAnyNotEmpty(null) = false
+ * StringUtils.isAnyNotEmpty(null, "foo")  = true
+ * StringUtils.isAnyNotEmpty("", "bar")= true
+ * StringUtils.isAnyNotEmpty("bob", "")= true
+ * StringUtils.isAnyNotEmpty("  bob  ", null)  = true
+ * StringUtils.isAnyNotEmpty(" ", "bar")   = true
+ * StringUtils.isAnyNotEmpty("foo", "bar") = true
+ * 
+ *
+ * @param css  the CharSequences to check, may be null or empty
+ * @return {@code true} if any of the CharSequences are empty or null
+ * @since 3.5
+ */
+public static boolean isAnyNotEmpty(final CharSequence... css) {
+  if (ArrayUtils.isEmpty(css)) {
+return true;
--- End diff --

I took the same behaviour as isAnyBlank()/isAnyEmpty() but maybe those 
should return false too. It would make more sense.


---
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] [Resolved] (LANG-787) Add method removeIgnoreCase(String, String) to StringUtils

[Benedikt Ritter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved LANG-787.
--
Resolution: Fixed

Fixed in commit cac7a60abf0a4451a5c80ef57343a14ea1ba443f.

Thank you!

> Add method removeIgnoreCase(String, String) to StringUtils
> --
>
> Key: LANG-787
> URL: https://issues.apache.org/jira/browse/LANG-787
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 3.1
>Reporter: david cogen
>Assignee: Benedikt Ritter
>Priority: Minor
> Fix For: 3.5
>
> Attachments: IgnoreCaseForRemoveAndReplace.patch
>
>
> removeStartIgnoreCase() and removeEndIgnoreCase() exist, so why not 
> removeIgnoreCase()
> Specifically:
> String removeIgnoreCase(String str, String remove)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-787) Add method removeIgnoreCase(String, String) to StringUtils

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518824#comment-15518824
 ] 

ASF GitHub Bot commented on LANG-787:
-

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/146


> Add method removeIgnoreCase(String, String) to StringUtils
> --
>
> Key: LANG-787
> URL: https://issues.apache.org/jira/browse/LANG-787
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 3.1
>Reporter: david cogen
>Priority: Minor
> Fix For: 3.5
>
> Attachments: IgnoreCaseForRemoveAndReplace.patch
>
>
> removeStartIgnoreCase() and removeEndIgnoreCase() exist, so why not 
> removeIgnoreCase()
> Specifically:
> String removeIgnoreCase(String str, String remove)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-787) Add method removeIgnoreCase(String, String) to StringUtils

[Benedikt Ritter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated LANG-787:
-
Fix Version/s: (was: Review Patch)
   3.5

> Add method removeIgnoreCase(String, String) to StringUtils
> --
>
> Key: LANG-787
> URL: https://issues.apache.org/jira/browse/LANG-787
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 3.1
>Reporter: david cogen
>Priority: Minor
> Fix For: 3.5
>
> Attachments: IgnoreCaseForRemoveAndReplace.patch
>
>
> removeStartIgnoreCase() and removeEndIgnoreCase() exist, so why not 
> removeIgnoreCase()
> Specifically:
> String removeIgnoreCase(String str, String remove)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #146: LANG-787: Add StringUtils#removeIgnoreCase

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/146


---
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] (LANG-787) Add method removeIgnoreCase(String, String) to StringUtils

[Benedikt Ritter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated LANG-787:
-
Summary: Add method removeIgnoreCase(String, String) to StringUtils  (was: 
StringUtils.RemoveIgnoreCase desired)

> Add method removeIgnoreCase(String, String) to StringUtils
> --
>
> Key: LANG-787
> URL: https://issues.apache.org/jira/browse/LANG-787
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 3.1
>Reporter: david cogen
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: IgnoreCaseForRemoveAndReplace.patch
>
>
> removeStartIgnoreCase() and removeEndIgnoreCase() exist, so why not 
> removeIgnoreCase()
> Specifically:
> String removeIgnoreCase(String str, String remove)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #189: new impl of LevenshteinDistance

[britter]

Github user britter commented on the issue:

https://github.com/apache/commons-lang/pull/189
  
@kinow can you take the lead in reviewing this?


---
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 pull request #192: Lang 1255: Add DateUtils.toCalendar(Date, Ti...

[britter]

Github user britter commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/192#discussion_r80358050
  
--- Diff: src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java ---
@@ -693,6 +693,43 @@ public void testToCalendar() {
 // expected
 }
 }
+
+
//---
+@Test
+public void testToCalendarWithDate() {
+assertEquals("Convert Date and TimeZone to a Calendar, but failed 
to get the Date back", date1, DateUtils.toCalendar(date1, zone).getTime());
+try {
+DateUtils.toCalendar(null, zone);
+fail("Expected NullPointerException to be thrown");
+} catch(final NullPointerException npe) {
+// expected
+}
+}
+
+
//---
+@Test
+public void testToCalendarWithTimeZone() {
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the TimeZone back", zone, DateUtils.toCalendar(date1, 
zone).getTimeZone());
+try {
+DateUtils.toCalendar(date1, null);
+fail("Expected NullPointerException to be thrown");
+} catch(final NullPointerException npe) {
+// expected
+}
+}
+
+  //---
+@Test
+public void testToCalendarWithDateAndTimeZone() {
+try {
+   Calendar c = DateUtils.toCalendar(date2, defaultZone);
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the Date back", date2, c.getTime());
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the TimeZone back", defaultZone, c.getTimeZone());
--- End diff --

This looks redundant to me, since `testToCalendarWithDate()` already tests 
that the date has been set and `testToCalendarWithTimeZone()` already tests, 
that the timeZone has been set.


---
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 pull request #192: Lang 1255: Add DateUtils.toCalendar(Date, Ti...

[britter]

Github user britter commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/192#discussion_r80357986
  
--- Diff: src/main/java/org/apache/commons/lang3/time/DateUtils.java ---
@@ -668,6 +668,19 @@ public static Calendar toCalendar(final Date date) {
 
 
//---
 /**
+ * Converts a {@code Date} of a given {@code TimeZone} into a {@code 
Calendar}
+ * @param date the date to convert to a Calendar
+ * @param timeZone the time zone of the @{code date}
+ * @return
--- End diff --

Missing JavaDoc


---
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 pull request #192: Lang 1255: Add DateUtils.toCalendar(Date, Ti...

[britter]

Github user britter commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/192#discussion_r80358033
  
--- Diff: src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java ---
@@ -693,6 +693,43 @@ public void testToCalendar() {
 // expected
 }
 }
+
+
//---
+@Test
+public void testToCalendarWithDate() {
+assertEquals("Convert Date and TimeZone to a Calendar, but failed 
to get the Date back", date1, DateUtils.toCalendar(date1, zone).getTime());
+try {
+DateUtils.toCalendar(null, zone);
+fail("Expected NullPointerException to be thrown");
+} catch(final NullPointerException npe) {
+// expected
+}
+}
+
+
//---
+@Test
+public void testToCalendarWithTimeZone() {
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the TimeZone back", zone, DateUtils.toCalendar(date1, 
zone).getTimeZone());
+try {
+DateUtils.toCalendar(date1, null);
+fail("Expected NullPointerException to be thrown");
+} catch(final NullPointerException npe) {
+// expected
+}
+}
+
+  //---
+@Test
+public void testToCalendarWithDateAndTimeZone() {
+try {
+   Calendar c = DateUtils.toCalendar(date2, defaultZone);
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the Date back", date2, c.getTime());
+   assertEquals("Convert Date and TimeZone to a Calendar, but 
failed to get the TimeZone back", defaultZone, c.getTimeZone());
+   // expected
+} catch(final NullPointerException npe) {
+   fail("Expected NullPointerException to be thrown");
--- End diff --

I don't understand this code. Why is a `NullPointerException` expected at 
this point?


---
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] (JCS-119) replace synchronized blocks by java locks or concurrenhashmap

[Thomas Vandahl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vandahl updated JCS-119:
---
Fix Version/s: (was: jcs-2.0-beta-2)
   jcs-2.1

> replace synchronized blocks by java locks or concurrenhashmap
> -
>
> Key: JCS-119
> URL: https://issues.apache.org/jira/browse/JCS-119
> Project: Commons JCS
>  Issue Type: Improvement
>Reporter: Romain Manni-Bucau
> Fix For: jcs-2.1
>
>
> A cache is typically used in a concurrent environment. Since Java 6 using a 
> ReentrantLock is faster than synchronized so can be interesting to replace 
> synchronized blocks by a lock.
> Places i'm thinking about:
> * CompositeCache
> * AbstractDoubleLinkedListMemoryCache
> * LHMLRUMemoryCache
> * DoubleLinkedList
> * LRUMap
> * SingleLinkedList
> * SortedPreferentialArray
> Some places where replacing a HashMap by a ConcurrentHashMap can allow to get 
> rid of synchronized without needing a lock:
> * CacheEventQueue
> * AbstractDiskCache
> * CacheWatchRepairable
> There are other places but this is the main I saw.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JCS-100) JCS never going out of the dispose methode

[Thomas Vandahl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vandahl resolved JCS-100.

   Resolution: Cannot Reproduce
Fix Version/s: jcs-2.0-beta-2

> JCS never going out of the dispose methode
> --
>
> Key: JCS-100
> URL: https://issues.apache.org/jira/browse/JCS-100
> Project: Commons JCS
>  Issue Type: Bug
>  Components: Composite Cache
>Affects Versions: jcs-1.3
> Environment: Windows
>Reporter: Jean-Marc Spaggiari
> Fix For: jcs-2.0-beta-2
>
>
> I have an application using many threads all calling JCS. When I close the 
> application, the cache is usually working fine, but sometime, it stays 
> stucked on the dispose methode.
> The cacheEventQueue never going empty. Then it's looping on while ( keepGoing 
> ) and never ending. I have to kill the application to exit.
> It's difficult to reproduce. There is no fixed pattern so far.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #193: Add isAnyNotEmpty() and isAnyNotBlank() to S...

[britter]

Github user britter commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/193#discussion_r80357934
  
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -358,6 +387,36 @@ public static boolean isAnyBlank(final CharSequence... 
css) {
 }
 
 /**
+ * Checks if any one of the CharSequences are not blank ("") or 
null and not whitespace only..
+ *
+ * 
+ * StringUtils.isAnyNotBlank(null) = false
+ * StringUtils.isAnyNotBlank(null, "foo")  = true
+ * StringUtils.isAnyNotBlank(null, null)   = false
+ * StringUtils.isAnyNotBlank("", "bar")= true
+ * StringUtils.isAnyNotBlank("bob", "")= true
+ * StringUtils.isAnyNotBlank("  bob  ", null)  = true
+ * StringUtils.isAnyNotBlank(" ", "bar")   = true
+ * StringUtils.isAnyNotBlank("foo", "bar") = false
+ * 
+ *
+ * @param css  the CharSequences to check, may be null or empty
+ * @return {@code true} if any of the CharSequences are not blank or 
null or whitespace only
+ * @since 3.5
+ */
+public static boolean isAnyNotBlank(final CharSequence... css) {
+  if (ArrayUtils.isEmpty(css)) {
+return true;
--- End diff --

See above


---
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] (JCS-166) TCP Lateral cache listen on all interfaces

[Thomas Vandahl (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518803#comment-15518803
 ] 

Thomas Vandahl commented on JCS-166:


Patches are welcome.

> TCP Lateral cache listen on all interfaces
> --
>
> Key: JCS-166
> URL: https://issues.apache.org/jira/browse/JCS-166
> Project: Commons JCS
>  Issue Type: Improvement
>  Components: TCP Lateral Cache
>Affects Versions: jcs-2.0-beta-1
> Environment: linux
>Reporter: Philippe Perrault
>
> TCP lateral cache listener is listening on all interfaces.
> it would be nice to be able to set a specific one



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #193: Add isAnyNotEmpty() and isAnyNotBlank() to S...

[britter]

Github user britter commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/193#discussion_r80357925
  
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -258,6 +258,35 @@ public static boolean isAnyEmpty(final CharSequence... 
css) {
 }
 
 /**
+ * Checks if any one of the CharSequences are not empty ("") or 
null.
+ *
+ * 
+ * StringUtils.isAnyNotEmpty(null) = false
+ * StringUtils.isAnyNotEmpty(null, "foo")  = true
+ * StringUtils.isAnyNotEmpty("", "bar")= true
+ * StringUtils.isAnyNotEmpty("bob", "")= true
+ * StringUtils.isAnyNotEmpty("  bob  ", null)  = true
+ * StringUtils.isAnyNotEmpty(" ", "bar")   = true
+ * StringUtils.isAnyNotEmpty("foo", "bar") = true
+ * 
+ *
+ * @param css  the CharSequences to check, may be null or empty
+ * @return {@code true} if any of the CharSequences are empty or null
+ * @since 3.5
+ */
+public static boolean isAnyNotEmpty(final CharSequence... css) {
+  if (ArrayUtils.isEmpty(css)) {
+return true;
--- End diff --

Shouldn't this return false? An empty Array does not contain any non empty 
CharSequences. WDYT?


---
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] (JCS-167) AbstractDiskCache.getKeySet() returns inconsistent key set

[Thomas Vandahl (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518801#comment-15518801
 ] 

Thomas Vandahl commented on JCS-167:


Care to provide a patch?

> AbstractDiskCache.getKeySet() returns inconsistent key set
> --
>
> Key: JCS-167
> URL: https://issues.apache.org/jira/browse/JCS-167
> Project: Commons JCS
>  Issue Type: Bug
>  Components: Composite Cache, Indexed Disk Cache
>Affects Versions: jcs-1.3, jcs-2.0-beta-1
>Reporter: Alexey Stepanov
>
> _getKeySet()_ method implementations in disk caches (Block and Index) is not 
> aware of purgatory inside _AbstractDiskCache_.
> So _CacheAccess.getCacheControl().getKeySet()_ as well as 
> GroupCacheAccess.getGroupKeys() returns key set that is inconsistent with 
> whole cache state. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CSV-197) CSVParser doesn't close the underlying handle after iteration

[Benedikt Ritter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CSV-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated CSV-197:

Fix Version/s: 1.4.1

> CSVParser doesn't close the underlying handle after iteration
> -
>
> Key: CSV-197
> URL: https://issues.apache.org/jira/browse/CSV-197
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Parser
>Reporter: Prateek Rungta
>Priority: Minor
> Fix For: Patch Needed, Discussion, 1.4.1
>
>
> The following code leaks file handles:
> {code}
> CSVParser parser = // setup parser
> for (CSVRecord rec: parser) {
> }
> // leak
> {code}
> I'd expect the underlying iterator to close() if it's finished iterating. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CSV-197) CSVParser doesn't close the underlying handle after iteration

[Benedikt Ritter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CSV-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated CSV-197:

Fix Version/s: Discussion
   Patch Needed

> CSVParser doesn't close the underlying handle after iteration
> -
>
> Key: CSV-197
> URL: https://issues.apache.org/jira/browse/CSV-197
> Project: Commons CSV
>  Issue Type: Bug
>  Components: Parser
>Reporter: Prateek Rungta
>Priority: Minor
> Fix For: Patch Needed, Discussion, 1.4.1
>
>
> The following code leaks file handles:
> {code}
> CSVParser parser = // setup parser
> for (CSVRecord rec: parser) {
> }
> // leak
> {code}
> I'd expect the underlying iterator to close() if it's finished iterating. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CSV-196) Store the info of whether a field is enclosed by quotes

[Benedikt Ritter (JIRA)]

[ 
https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518771#comment-15518771
 ] 

Benedikt Ritter commented on CSV-196:
-

Hello [~mattsun],

would you like to contribute a patch?

BR,
Benedikt

> Store the info of whether a field is enclosed by quotes
> ---
>
> Key: CSV-196
> URL: https://issues.apache.org/jira/browse/CSV-196
> Project: Commons CSV
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.4
>Reporter: Matt Sun
>  Labels: easyfix, features, patch
> Fix For: Patch Needed
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It will be good to have CSVParser class to store the info of whether a field 
> was enclosed by quotes in the original source file.
> For example, for this data sample:
> A, B, C
> a1, "b1", c1
> CSVParser gives us record a1, b1, c1, which is helpful because it parsed 
> double quotes, but we also lost the information of original data at the same 
> time. We can't tell from the CSVRecord returned whether the original data is 
> enclosed by double quotes or not.
> In our use case, we are integrating Apache Hadoop APIs with Commons CSV.  CSV 
> is one kind of input of Hadoop Jobs, which should support splitting input 
> data. To accurately split a CSV file into pieces, we need to count the bytes 
> of  data CSVParser actually read. CSVParser doesn't have accurate information 
> of whether a field was enclosed by quotes, neither does it store raw data of 
> the original source. Downstream users of commons CSVParser is not able to get 
> those info.
> To suggest a fix: Extend the token/CSVRecord to have a boolean field 
> indicating whether the column was enclosed by quotes. While Lexer is doing 
> getNextToken, set the flag if a field is encapsulated and successfully parsed.
> I find another issue reported with similar request, but it was marked as 
> resolved: [CSV91] 
> https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CSV-196) Store the info of whether a field is enclosed by quotes

[Benedikt Ritter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated CSV-196:

Fix Version/s: Patch Needed

> Store the info of whether a field is enclosed by quotes
> ---
>
> Key: CSV-196
> URL: https://issues.apache.org/jira/browse/CSV-196
> Project: Commons CSV
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.4
>Reporter: Matt Sun
>  Labels: easyfix, features, patch
> Fix For: Patch Needed
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It will be good to have CSVParser class to store the info of whether a field 
> was enclosed by quotes in the original source file.
> For example, for this data sample:
> A, B, C
> a1, "b1", c1
> CSVParser gives us record a1, b1, c1, which is helpful because it parsed 
> double quotes, but we also lost the information of original data at the same 
> time. We can't tell from the CSVRecord returned whether the original data is 
> enclosed by double quotes or not.
> In our use case, we are integrating Apache Hadoop APIs with Commons CSV.  CSV 
> is one kind of input of Hadoop Jobs, which should support splitting input 
> data. To accurately split a CSV file into pieces, we need to count the bytes 
> of  data CSVParser actually read. CSVParser doesn't have accurate information 
> of whether a field was enclosed by quotes, neither does it store raw data of 
> the original source. Downstream users of commons CSVParser is not able to get 
> those info.
> To suggest a fix: Extend the token/CSVRecord to have a boolean field 
> indicating whether the column was enclosed by quotes. While Lexer is doing 
> getNextToken, set the flag if a field is encapsulated and successfully parsed.
> I find another issue reported with similar request, but it was marked as 
> resolved: [CSV91] 
> https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)