[GitHub] [commons-collections] dota17 commented on issue #84: [COLLECTIONS 708] Add hashCode method to CollectionUtils

2019-09-20 Thread GitBox
dota17 commented on issue #84: [COLLECTIONS 708] Add hashCode method to 
CollectionUtils
URL: 
https://github.com/apache/commons-collections/pull/84#issuecomment-533467751
 
 
   > 我认为你缺少输入上的null集合的测试用例。请运行网站构建并检查新代码是否获得100%的代码覆盖率`mvn clean site -P 
jacoco`。
   > ...谢谢!
   
   Sorry, this is the first time I have submitted code for Apache project. Many 
details are problematic.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-collections] dota17 commented on issue #84: [COLLECTIONS 708] Add hashCode method to CollectionUtils

2019-09-20 Thread GitBox
dota17 commented on issue #84: [COLLECTIONS 708] Add hashCode method to 
CollectionUtils
URL: 
https://github.com/apache/commons-collections/pull/84#issuecomment-533467975
 
 
   > I think you are missing a test case for a null collection on input. Please 
run the site build and check that the new code gets 100% code coverage `mvn 
clean site -P jacoco`.
   > ... and thank you!
   
   Sorry, this is the first time I have submitted code for Apache project. Many 
details are problematic.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-collections] dota17 removed a comment on issue #84: [COLLECTIONS 708] Add hashCode method to CollectionUtils

2019-09-20 Thread GitBox
dota17 removed a comment on issue #84: [COLLECTIONS 708] Add hashCode method to 
CollectionUtils
URL: 
https://github.com/apache/commons-collections/pull/84#issuecomment-533467751
 
 
   > 我认为你缺少输入上的null集合的测试用例。请运行网站构建并检查新代码是否获得100%的代码覆盖率`mvn clean site -P 
jacoco`。
   > ...谢谢!
   
   Sorry, this is the first time I have submitted code for Apache project. Many 
details are problematic.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-fileupload] codecracker2014 opened a new pull request #21: Adding capability to take max upload size per request.

2019-09-20 Thread GitBox
codecracker2014 opened a new pull request #21: Adding capability to take max 
upload size per request.
URL: https://github.com/apache/commons-fileupload/pull/21
 
 
   As of now FileUploadBase has sizeMax which is global for all uploads, in 
many cases it is required to calculate this limit based on request.
   
   
https://stackoverflow.com/questions/16585866/changing-file-size-limit-maxuploadsize-depending-on-the-controller


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-fileupload] codecracker2014 closed pull request #21: Adding capability to take max upload size per request.

2019-09-20 Thread GitBox
codecracker2014 closed pull request #21: Adding capability to take max upload 
size per request.
URL: https://github.com/apache/commons-fileupload/pull/21
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-fileupload] codecracker2014 opened a new pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1

2019-09-20 Thread GitBox
codecracker2014 opened a new pull request #22: Adding capability to take max 
upload size per request.Fileupload 1 3 1
URL: https://github.com/apache/commons-fileupload/pull/22
 
 
   As of now FileUploadBase has sizeMax which is global for all uploads, in 
many cases it is required to calculate this limit based on request.
   
   
https://stackoverflow.com/questions/16585866/changing-file-size-limit-maxuploadsize-depending-on-the-controller


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-fileupload] garydgregory commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1

2019-09-20 Thread GitBox
garydgregory commented on a change in pull request #22: Adding capability to 
take max upload size per request.Fileupload 1 3 1
URL: https://github.com/apache/commons-fileupload/pull/22#discussion_r326683363
 
 

 ##
 File path: src/main/java/org/apache/commons/fileupload/FileUploadBase.java
 ##
 @@ -205,6 +205,18 @@ public static boolean 
isMultipartContent(HttpServletRequest req) {
 public long getSizeMax() {
 return sizeMax;
 }
+
+/**
+ * This method enables subclassed to set 
 
 Review comment:
   Should start with "Gets..."


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-fileupload] garydgregory commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1

2019-09-20 Thread GitBox
garydgregory commented on a change in pull request #22: Adding capability to 
take max upload size per request.Fileupload 1 3 1
URL: https://github.com/apache/commons-fileupload/pull/22#discussion_r326683095
 
 

 ##
 File path: pom.xml
 ##
 @@ -26,7 +26,7 @@
 
   commons-fileupload
   commons-fileupload
-  1.3.1-SNAPSHOT
+  1.3.1
 
 Review comment:
   This should never be in a PR .


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-fileupload] garydgregory commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1

2019-09-20 Thread GitBox
garydgregory commented on a change in pull request #22: Adding capability to 
take max upload size per request.Fileupload 1 3 1
URL: https://github.com/apache/commons-fileupload/pull/22#discussion_r326683484
 
 

 ##
 File path: src/main/java/org/apache/commons/fileupload/FileUploadBase.java
 ##
 @@ -205,6 +205,18 @@ public static boolean 
isMultipartContent(HttpServletRequest req) {
 public long getSizeMax() {
 return sizeMax;
 }
+
+/**
+ * This method enables subclassed to set 
+ allowed size per request if needed.
+ * @param ctx
+ * @return
+ */
 
 Review comment:
   Fill in missing tags. Add since tag.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-fileupload] garydgregory commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1

2019-09-20 Thread GitBox
garydgregory commented on a change in pull request #22: Adding capability to 
take max upload size per request.Fileupload 1 3 1
URL: https://github.com/apache/commons-fileupload/pull/22#discussion_r326683768
 
 

 ##
 File path: 
src/main/java/org/apache/commons/fileupload/servlet/ServletRequestContext.java
 ##
 @@ -123,5 +123,14 @@ public String toString() {
 Long.valueOf(this.contentLength()),
 this.getContentType());
 }
+
+ /**
+ *
+ * @return
 
 Review comment:
   This method is not used in the PR.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-fileupload] Stzx commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1

2019-09-20 Thread GitBox
Stzx commented on a change in pull request #22: Adding capability to take max 
upload size per request.Fileupload 1 3 1
URL: https://github.com/apache/commons-fileupload/pull/22#discussion_r326707673
 
 

 ##
 File path: src/main/java/org/apache/commons/fileupload/FileUploadBase.java
 ##
 @@ -205,6 +205,18 @@ public static boolean 
isMultipartContent(HttpServletRequest req) {
 public long getSizeMax() {
 return sizeMax;
 }
+
+/**
+ * This method enables subclassed to set 
+ allowed size per request if needed.
+ * @param ctx
+ * @return
+ */
 
 Review comment:
   What is the role of the `ctx` parameter?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [commons-lang] coveralls edited a comment on issue #458: [LANG-1426] Corrected usage examples in Javadocs

2019-09-20 Thread GitBox
coveralls edited a comment on issue #458: [LANG-1426] Corrected usage examples 
in Javadocs
URL: https://github.com/apache/commons-lang/pull/458#issuecomment-531573214
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/25837031/badge)](https://coveralls.io/builds/25837031)
   
   Coverage increased (+0.007%) to 95.21% when pulling 
**358c0d6f6fd3b0ff979f650ee8bc2ae45e7ea336 on 
mikkomaunu:LANG-1426-StringUtils-truncate-Javadoc** into 
**29723e851ca56aa621165130049e588980c5a5e7 on apache:master**.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Work logged] (LANG-1426) JavaDoc issue on StringUtils.truncate

2019-09-20 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/LANG-1426?focusedWorklogId=315827&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-315827
 ]

ASF GitHub Bot logged work on LANG-1426:


Author: ASF GitHub Bot
Created on: 20/Sep/19 17:41
Start Date: 20/Sep/19 17:41
Worklog Time Spent: 10m 
  Work Description: coveralls commented on issue #458: [LANG-1426] 
Corrected usage examples in Javadocs
URL: https://github.com/apache/commons-lang/pull/458#issuecomment-531573214
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/25837031/badge)](https://coveralls.io/builds/25837031)
   
   Coverage increased (+0.007%) to 95.21% when pulling 
**358c0d6f6fd3b0ff979f650ee8bc2ae45e7ea336 on 
mikkomaunu:LANG-1426-StringUtils-truncate-Javadoc** into 
**29723e851ca56aa621165130049e588980c5a5e7 on apache:master**.
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 315827)
Time Spent: 1h 20m  (was: 1h 10m)

> JavaDoc issue on StringUtils.truncate
> -
>
> Key: LANG-1426
> URL: https://issues.apache.org/jira/browse/LANG-1426
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Jeff
>Priority: Trivial
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Two of the examples on the method StringUtils.truncate(String, int, int) are 
> incorrect:
>  * StringUtils.truncate("abcdefghijklmno", Integer.MIN_VALUE, 10) = 
> "abcdefghij"
>  * StringUtils.truncate("abcdefghijklmno", Integer.MIN_VALUE, 
> Integer.MAX_VALUE) = "abcdefghijklmno"
> Both of the above actually throw IllegalArgumentException's.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Reopened] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0

2019-09-20 Thread Phil Steitz (Jira)


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

Phil Steitz reopened POOL-356:
--

I am not sure this issue is really valid, but assuming there is a real use case 
to have maxIdle set to 0, the committed fix is not correct.  create() can 
return null and that will result in a null object added to the idle queue.  If 
I am missing something and it really does make sense to have minidle 0 (so you 
are basically just using the pool as an object factory), the correct fix is to 
call `ensureIdle(1, *false*);` after the call to destroy in returnObject (like 
it does for validation failures).  That will be a no-op if create returns null.

> deadlock if borrowObject gets called to fast and maxIdle is 0
> -
>
> Key: POOL-356
> URL: https://issues.apache.org/jira/browse/POOL-356
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.6.1
>
>
> I figured this while creating a unit test for OpenJPA. But also did see this 
> in real production with commons-dbcp2. See DBCP-513 for more info.
> See this comment for a precise explanation what happens 
> https://issues.apache.org/jira/browse/DBCP-513?focusedCommentId=16660545&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16660545
> The problem is basically that the logic to immediately destroy a pool object 
> does not notify the DeLinkedQueue:
> {code}
> if (isClosed() || maxIdleSave > -1 && maxIdleSave <= 
> idleObjects.size()) {
> try {
> destroy(p);
> {code}
> But the borrowObject code is locking on that condition...
> {code}
> if (borrowMaxWaitMillis < 0) {
> p = idleObjects.takeFirst();
> } 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0

2019-09-20 Thread Phil Steitz (Jira)


[ 
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934737#comment-16934737
 ] 

Phil Steitz edited comment on POOL-356 at 9/20/19 8:27 PM:
---

I am not sure this issue is really valid, but assuming there is a real use case 
to have maxIdle set to 0, the committed fix is not correct.  create() can 
return null and that will result in a null object added to the idle queue.  If 
I am missing something and it really does make sense to have minidle 0 (so you 
are basically just using the pool as an object factory), the correct fix is to 
call
{code:java}
ensureIdle(1, false); {code}
after the call to destroy in returnObject (like it does for validation 
failures).  That will be a no-op if create returns null.


was (Author: psteitz):
I am not sure this issue is really valid, but assuming there is a real use case 
to have maxIdle set to 0, the committed fix is not correct.  create() can 
return null and that will result in a null object added to the idle queue.  If 
I am missing something and it really does make sense to have minidle 0 (so you 
are basically just using the pool as an object factory), the correct fix is to 
call `ensureIdle(1, *false*);` after the call to destroy in returnObject (like 
it does for validation failures).  That will be a no-op if create returns null.

> deadlock if borrowObject gets called to fast and maxIdle is 0
> -
>
> Key: POOL-356
> URL: https://issues.apache.org/jira/browse/POOL-356
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.6.1
>
>
> I figured this while creating a unit test for OpenJPA. But also did see this 
> in real production with commons-dbcp2. See DBCP-513 for more info.
> See this comment for a precise explanation what happens 
> https://issues.apache.org/jira/browse/DBCP-513?focusedCommentId=16660545&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16660545
> The problem is basically that the logic to immediately destroy a pool object 
> does not notify the DeLinkedQueue:
> {code}
> if (isClosed() || maxIdleSave > -1 && maxIdleSave <= 
> idleObjects.size()) {
> try {
> destroy(p);
> {code}
> But the borrowObject code is locking on that condition...
> {code}
> if (borrowMaxWaitMillis < 0) {
> p = idleObjects.takeFirst();
> } 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0

2019-09-20 Thread Phil Steitz (Jira)


[ 
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934737#comment-16934737
 ] 

Phil Steitz edited comment on POOL-356 at 9/20/19 8:44 PM:
---

I am not sure this issue is really valid, but assuming there is a real use case 
to have maxIdle set to 0, the committed fix is not correct.  create() can 
return null and that will result in NPE in the put to idleObjects.  If I am 
missing something and it really does make sense to have minidle 0 (so you are 
basically just using the pool as an object factory), the correct fix is to call
{code:java}
ensureIdle(1, false); {code}
after the call to destroy in returnObject (like it does for validation 
failures).  That will be a no-op if create returns null.


was (Author: psteitz):
I am not sure this issue is really valid, but assuming there is a real use case 
to have maxIdle set to 0, the committed fix is not correct.  create() can 
return null and that will result in a null object added to the idle queue.  If 
I am missing something and it really does make sense to have minidle 0 (so you 
are basically just using the pool as an object factory), the correct fix is to 
call
{code:java}
ensureIdle(1, false); {code}
after the call to destroy in returnObject (like it does for validation 
failures).  That will be a no-op if create returns null.

> deadlock if borrowObject gets called to fast and maxIdle is 0
> -
>
> Key: POOL-356
> URL: https://issues.apache.org/jira/browse/POOL-356
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.6.1
>
>
> I figured this while creating a unit test for OpenJPA. But also did see this 
> in real production with commons-dbcp2. See DBCP-513 for more info.
> See this comment for a precise explanation what happens 
> https://issues.apache.org/jira/browse/DBCP-513?focusedCommentId=16660545&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16660545
> The problem is basically that the logic to immediately destroy a pool object 
> does not notify the DeLinkedQueue:
> {code}
> if (isClosed() || maxIdleSave > -1 && maxIdleSave <= 
> idleObjects.size()) {
> try {
> destroy(p);
> {code}
> But the borrowObject code is locking on that condition...
> {code}
> if (borrowMaxWaitMillis < 0) {
> p = idleObjects.takeFirst();
> } 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEOMETRY-32) BSPTree Updates

2019-09-20 Thread Matt Juntunen (Jira)


[ 
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934868#comment-16934868
 ] 

Matt Juntunen commented on GEOMETRY-32:
---

{quote}Really? This is actually a question: I don't know why it is a 
requirement (nor where it is defined).
{quote}
I picture a region as a connected subset of the points in a space (see 
[here|http://example.com/]). Therefore, the transformed region should be the 
same as applying the transform to all of the points in that subset. I don't 
have a formal proof of that statement, but I believe it holds nonetheless. The 
flipping of the inside and outside of the regions we're talking about here is 
simply a by-product of the fact that we're using oriented hyperplanes to test 
points for inclusion in the region. For example, if we had a triangle in 2D and 
defined our region using 3 points and barycentric coordinates instead of 
oriented hyperplanes, then there would be no flipping of the inside and outside 
of the region when transformed by a reflection. The same would be true if we 
used unoriented line segments and winding numbers. The requirement to flip the 
inside and outside of our oriented-hyperplane-bounded regions in certain 
situations is just a requirement of how we're implementing the region inclusion 
test, and not a property of the region itself.

> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
>  Issue Type: Improvement
>  Components: core
>Reporter: Matt Juntunen
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The following updates should be made to the BSPTree class:
> - add an {{isLeaf()}} method to replace all of the {{node.getCut() == null}} 
> expressions
> - add unit tests
> _Edit [2019-02-17]:_
> Additional goals:
> - Refactor the API to split the idea of a general BSPTree and a BSPTree used 
> for defining in/out regions. This could result in a BSPTree interface and a 
> RegionBSPTree interface. The goal here is to allow end-users to create their 
> own extensions of these classes and specialize them for their own 
> applications (for example, to implement spatial sorting or other algorithms). 
> This will be one of the only planned extension points in the library.
> - Make the API easier to use and extend and reduce the necessity of casting 
> (especially unchecked casting) as much as possible.
> - Add the idea of convex subhyperplanes to allow for more efficient tree 
> construction.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (POOL-376) invalidateObject should not return NullPointerException

2019-09-20 Thread M Sazzadul Hoque (Jira)
M Sazzadul Hoque created POOL-376:
-

 Summary: invalidateObject should not return NullPointerException
 Key: POOL-376
 URL: https://issues.apache.org/jira/browse/POOL-376
 Project: Commons Pool
  Issue Type: Improvement
Affects Versions: 2.6.2
Reporter: M Sazzadul Hoque


GenericObjectPool.invalidateObject(T obj) should not return 
NullPointerException when obj is not null.

Please see following stack trace:
{code:java}
Caused by: java.lang.NullPointerException
at 
org.apache.commons.pool2.impl.LinkedBlockingDeque.putLast(LinkedBlockingDeque.java:454)
at 
org.apache.commons.pool2.impl.LinkedBlockingDeque.put(LinkedBlockingDeque.java:788)
at 
org.apache.commons.pool2.impl.GenericObjectPool.destroy(GenericObjectPool.java:939)
at 
org.apache.commons.pool2.impl.GenericObjectPool.invalidateObject(GenericObjectPool.java:618)
{code}
Please make this available for JDK 1.7.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)