[GitHub] [commons-fileupload] codecracker2014 commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1
codecracker2014 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_r326854899
##
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:
ctx can be used to get request attributes which can be used in calculating
allowed max size for particular request.
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 commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1
codecracker2014 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_r326854928
##
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 to be used in subclasses of FileUploadBase to get request for
accessing request attributes.
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] [Commented] (POOL-376) invalidateObject should not return NullPointerException
[
https://issues.apache.org/jira/browse/POOL-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935066#comment-16935066
]
Phil Steitz commented on POOL-376:
--
This is a regression caused by the fix for Pool-356.
> 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
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{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}
> Apparent reason: In {{destroy(PooledObject toDestroy)}}, create() may
> return null even though {{toDestroy}} is already destroyed.
> Please make the fix available for JDK 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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
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_r326854509
##
File path: src/main/java/org/apache/commons/fileupload/FileUploadBase.java
##
@@ -206,6 +206,18 @@ public long getSizeMax() {
return sizeMax;
}
+/**
+ * Gets allowed max size for current upload, subclasses can override this
method
+ * to calculate allowed size per request
+ * @param ctx requestContext - provides information related to current
upload request.
+ * @return max size allowed for current request
+ */
+public long getSizeMaxForThisRequest(RequestContext ctx) {
+return sizeMax;
Review comment:
What is the difference between this method implementation and the
`getSizeMax` method?
The `ctx` argument passed in is also not used.
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] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935037#comment-16935037
]
Matt Juntunen commented on GEOMETRY-32:
---
{quote}Wrong link.
{quote}
Oops. Here it is: [https://en.wikipedia.org/wiki/Region_(mathematics)]
{quote}Hence, shouldn't we hide this _implementation detail_ from the public API
{quote}
Yes. The fact that our hyperplane-bounded regions need to have their inside and
outside flipped in some situations is an implementation detail and is _not_
part of the public API. Users pass arbitrary {{Transform}} instances to the
regions and this logic is handled internally. However, the fact that some
{{Transform}} instances preserve spatial orientation _is_ part of the public
API, since it is a property of the transforms themselves. Users should not need
to worry about it unless they're implementing their own {{Transform}} classes,
which seems uneccessary. The provided classes handle all of the logic
transparently. Here are some examples. Note that I changed the method name from
{{preservesHandedness}} to {{preservesOrientation}} to be more generic.
{code:java}
// create some matrix transforms
Transform2D translate =
AffineTransformMatrix2D.createTranslation(Vector2D.of(1, 2));
translate.preservesOrientation(); // true
Transform2D reflectX = AffineTransformMatrix2D.createScale(-1, 1);
reflectX.preservesOrientation(); // false
// create some function-based transforms
Transform2D scale = FunctionTransform2D.from(p -> p.add(Vector2D.of(1, 2)));
scale.preservesOrientation(); // true
Transform2D reflectY = FunctionTransform2D.from(p -> Vector2D.of(p.getX(),
-p.getY()));
reflectY.preservesOrientation(); // false
// transform some regions
RegionBSPTree2D tree = createTree();
tree.transform(translate); // no inside/outside flipping
tree.transform(reflectY); // flips inside/outside
{code}
> 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] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935038#comment-16935038
]
Matt Juntunen commented on GEOMETRY-32:
---
Here is another useful link for this discussion:
https://en.wikipedia.org/wiki/Orientation_(vector_space)
> 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] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934983#comment-16934983
]
Gilles commented on GEOMETRY-32:
bq. see here
Wrong link.
bq. [...] just a requirement of how we're implementing the region inclusion
test, and not a property of the region itself.
Hence, shouldn't we hide this _implementation detail_ from the public API (in
the sense that application developers would/should never have any reason to set
the {{preserveHandedness}}, IIUC)?
> 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] [Commented] (POOL-376) invalidateObject should not return NullPointerException
[
https://issues.apache.org/jira/browse/POOL-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935067#comment-16935067
]
Phil Steitz commented on POOL-376:
--
Thanks for reporting this. The patch in the PR would fix the immediate
problem, but this code should not be in destroy(). See comments in POOL-356.
> 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
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{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}
> Apparent reason: In {{destroy(PooledObject toDestroy)}}, create() may
> return null even though {{toDestroy}} is already destroyed.
> Please make the fix available for JDK 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-fileupload] codecracker2014 commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1
codecracker2014 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_r326853601 ## File path: pom.xml ## @@ -26,7 +26,7 @@ commons-fileupload commons-fileupload - 1.3.1-SNAPSHOT + 1.3.1 Review comment: Thanks for your quick response i will raise PR for master and 1.3.1(I'm using this version and upgrade not possible at this moment). 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 commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1
codecracker2014 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_r326855041
##
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:
Updated
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 commented on a change in pull request #22: Adding capability to take max upload size per request.Fileupload 1 3 1
codecracker2014 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_r326855027
##
File path: src/main/java/org/apache/commons/fileupload/FileUploadBase.java
##
@@ -206,6 +206,18 @@ public long getSizeMax() {
return sizeMax;
}
+/**
+ * Gets allowed max size for current upload, subclasses can override this
method
+ * to calculate allowed size per request
+ * @param ctx requestContext - provides information related to current
upload request.
+ * @return max size allowed for current request
+ */
+public long getSizeMaxForThisRequest(RequestContext ctx) {
+return sizeMax;
Review comment:
ctx is to be used in subclasses of FileUploadBase, so that max allowed size
can be calculated based on request attributes at runtime. It's an extension
points to allow dynamic upload limit.
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] [Created] (POOL-376) invalidateObject should not return NullPointerException
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)
[jira] [Updated] (POOL-376) invalidateObject should not return NullPointerException
[
https://issues.apache.org/jira/browse/POOL-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
M Sazzadul Hoque updated POOL-376:
--
Description:
{{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}
Apparent reason: In {{destroy(PooledObject toDestroy)}}, create() may return
null even though {{toDestroy}} is already destroyed.
Please make the fix available for JDK 1.7.
was:
{{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}
Apparent reason: In {{destroy(PooledObject toDestroy)}} create() may return
null even though {{toDestroy}} is already destroyed.
Please make the fix available for JDK 1.7.
> 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
>Priority: Major
>
> {{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}
> Apparent reason: In {{destroy(PooledObject toDestroy)}}, create() may
> return null even though {{toDestroy}} is already destroyed.
> Please make the fix available for JDK 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (POOL-376) invalidateObject should not return NullPointerException
[
https://issues.apache.org/jira/browse/POOL-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
M Sazzadul Hoque updated POOL-376:
--
Description:
{{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}
Apparent reason: In {{destroy(PooledObject toDestroy)}} create() may return
null even though {{toDestroy}} is already destroyed.
Please make the fix available for JDK 1.7.
was:
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.
> 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
>Priority: Major
>
> {{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}
> Apparent reason: In {{destroy(PooledObject toDestroy)}} create() may
> return null even though {{toDestroy}} is already destroyed.
> Please make the fix available for JDK 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (POOL-376) invalidateObject should not return NullPointerException
[
https://issues.apache.org/jira/browse/POOL-376?focusedWorklogId=316077=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316077
]
ASF GitHub Bot logged work on POOL-376:
---
Author: ASF GitHub Bot
Created on: 21/Sep/19 07:12
Start Date: 21/Sep/19 07:12
Worklog Time Spent: 10m
Work Description: sazzad16 commented on pull request #24: POOL-376
invalidateObject should not throw NPE
URL: https://github.com/apache/commons-pool/pull/24
`GenericObjectPool.invalidateObject(T obj)` and/or
`GenericObjectPool.destroy(PooledObject toDestroy)` should not throw
NullPointerException when respective parameter (`obj/`toDestroy`) is not `null`.
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: 316077)
Remaining Estimate: 0h
Time Spent: 10m
> 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
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{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}
> Apparent reason: In {{destroy(PooledObject toDestroy)}}, create() may
> return null even though {{toDestroy}} is already destroyed.
> Please make the fix available for JDK 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-pool] sazzad16 opened a new pull request #24: POOL-376 invalidateObject should not throw NPE
sazzad16 opened a new pull request #24: POOL-376 invalidateObject should not throw NPE URL: https://github.com/apache/commons-pool/pull/24 `GenericObjectPool.invalidateObject(T obj)` and/or `GenericObjectPool.destroy(PooledObject toDestroy)` should not throw NullPointerException when respective parameter (`obj/`toDestroy`) is not `null`. 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] (POOL-376) invalidateObject should not return NullPointerException
[
https://issues.apache.org/jira/browse/POOL-376?focusedWorklogId=316080=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-316080
]
ASF GitHub Bot logged work on POOL-376:
---
Author: ASF GitHub Bot
Created on: 21/Sep/19 07:32
Start Date: 21/Sep/19 07:32
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #24: POOL-376
invalidateObject should not throw NPE
URL: https://github.com/apache/commons-pool/pull/24#issuecomment-533776196
[](https://coveralls.io/builds/25845625)
Coverage increased (+0.04%) to 84.37% when pulling
**bda049b6accfd54baeaf7931e127f314816d78bf on sazzad16:patch-1** into
**cb38a1b69384a3811d50d9eb0145683227fe8d51 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: 316080)
Time Spent: 20m (was: 10m)
> 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
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{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}
> Apparent reason: In {{destroy(PooledObject toDestroy)}}, create() may
> return null even though {{toDestroy}} is already destroyed.
> Please make the fix available for JDK 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-pool] coveralls commented on issue #24: POOL-376 invalidateObject should not throw NPE
coveralls commented on issue #24: POOL-376 invalidateObject should not throw NPE URL: https://github.com/apache/commons-pool/pull/24#issuecomment-533776196 [](https://coveralls.io/builds/25845625) Coverage increased (+0.04%) to 84.37% when pulling **bda049b6accfd54baeaf7931e127f314816d78bf on sazzad16:patch-1** into **cb38a1b69384a3811d50d9eb0145683227fe8d51 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] [Comment Edited] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935038#comment-16935038
]
Gilles edited comment on GEOMETRY-32 at 9/21/19 4:54 PM:
-
Here is another useful link for this discussion:
[https://en.wikipedia.org/wiki/Orientation_(vector_space)|https://en.wikipedia.org/wiki/Orientation_(vector_space)]
was (Author: mattjuntunen):
Here is another useful link for this discussion:
https://en.wikipedia.org/wiki/Orientation_(vector_space)
> 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] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935087#comment-16935087
]
Gilles commented on GEOMETRY-32:
The previous examples look nice. ;)
> 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)
[GitHub] [commons-fileupload] jochenw commented on issue #22: Adding capability to take max upload size per request.Fileupload 1 3 1
jochenw commented on issue #22: Adding capability to take max upload size per
request.Fileupload 1 3 1
URL: https://github.com/apache/commons-fileupload/pull/22#issuecomment-533821094
1. I'd support Gary's request, that you provide a PR for the current master,
and not the stable branch.
2. Well spotted, that you should use the RequestContext, to support both the
servlet, and the portlet case!
3. Rather than using a method getSizeMaxForThisRequest, I'd suggest a more
general approach, (The 1.4 branch is still open for API changes.) such as:
- Replace
> FileItemStream FileUploadBase.getItemIterator(RequestContext pCtx)
with a method
> FileItemRequest getItemIterator(RequestContext pCtx)
where FileItemRequest would contain methods like
void setMaxUploadSizeExceeded(Predicate pPredicate) {
}
FileItemStream getItemIterator();
On the other hand, rethinking that, it is probably a better idea, if I do
that myself.
>
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
