[jira] [Updated] (JXPATH-172) JXPathContext#getPointer claims that null will be returned if the XPath expr does not point to a valid node
[
https://issues.apache.org/jira/browse/JXPATH-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated JXPATH-172:
--
Summary: JXPathContext#getPointer claims that null will be returned if the
XPath expr does not point to a valid node (was: JXPathContext#getPointer
claims that null will be returned the the XPath expr does not point to a valid
node)
> JXPathContext#getPointer claims that null will be returned if the XPath expr
> does not point to a valid node
> ---
>
> Key: JXPATH-172
> URL: https://issues.apache.org/jira/browse/JXPATH-172
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> {quote}
> Traverses the xpath and returns a Pointer. A Pointer provides easy access to
> a property. If the xpath matches no properties in the graph, the pointer will
> be null.
> {quote}
> This is not true because not {{null}} is returned but {{NullPointer}}. This
> makes a tremendous difference.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MATH-1166) BicubicInterpolation may have a bug
[
https://issues.apache.org/jira/browse/MATH-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1166:
-
Attachment: MATH-1166.patch
I finally tracked down the bug, thanks to web page that showed a code excerpt
from the well-known "reference-that-cannot-be-named".
There were actually two bugs:
* one was indeed a transposition of the coefficient matrix,
* the other was that the implementation on Wikipedia was assuming a _one_-pixel
"delta" between samples.
In the attached patch, I've created new classes:
* {{BicubicInterpolatingFunction}}
* {{BicubicInterpolator}}
The reason is that the fix entailed the failure of the tests in
{{BicubicInterpolatingFunctionTest}} related to the methods providing the
partial derivatives functionality. A solution could have been to remove those
but it cannot be done because of backward compatibility.
The {{TricubicSplineInterpolator}} must be deprecated since it is based on the
buggy code, and the implementation requires the partial derivatives...
A problem remained in that the {{BicubicInterpolator}} needs to estimate the
derivatives in order to use the {{BicubicInterpolatingFunction}}. This entails
that, on the border of the sampling range, the interpolation is wrong. As a
workaround, the method "isValidPoint" is overridden, and for the "valid"
points, the interpolation is within a reasonable tolerance.
This is a weak point of the {{BicubicInterpolator}}, but in some cases (as in
the picture produced by Ajo's code), there could be less artefacts.
Is it OK to commit this patch?
Or do we proceed otherwise?
> BicubicInterpolation may have a bug
> ---
>
> Key: MATH-1166
> URL: https://issues.apache.org/jira/browse/MATH-1166
> Project: Commons Math
> Issue Type: Bug
>Reporter: Ajo Fod
> Attachments: Draw.java, MATH-1166.patch, myimage.jpg
>
>
> I plotted a random image with bicubic interpolation hoping to see something
> like this:
> http://en.wikipedia.org/wiki/Bicubic_interpolation
> ... but instead I got something weird.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MATH-1162) contains(Region region) method of AbstractRegion throws NullPointerException exception
[
https://issues.apache.org/jira/browse/MATH-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-1162.
-
Resolution: Fixed
Fix Version/s: 3.4
The issue has been fixed in the git repository (see commit 046e3a2).
Thanks for the report.
> contains(Region region) method of AbstractRegion throws
> NullPointerException exception
> --
>
> Key: MATH-1162
> URL: https://issues.apache.org/jira/browse/MATH-1162
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: tested on windows 8 and heroku
>Reporter: gün alppay
> Fix For: 3.4
>
>
> the contains call on
> org.apache.commons.math3.geometry.partitioning.AbstractRegion throws an
> exception in the sample below:
> {noformat}
> import org.apache.commons.math3.geometry.partitioning.Region;
> import org.apache.commons.math3.geometry.euclidean.twod.Vector2D;
> import org.apache.commons.math3.geometry.euclidean.twod.Euclidean2D;
> import org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet;
> class Test {
> public static void main(String[] args) {
> Region p = new PolygonsSet( 1.0e-10, new
> Vector2D(4.26719996532, -11.928637756014894),
> new
> Vector2D(4.26720026445, -14.12360595809307),
> new
> Vector2D(9.14400273694, -14.12360595809307),
> new
> Vector2D(9.14400233383, -11.928637756020067));
> Region w = new PolygonsSet( 1.0e-10, new
> Vector2D(2.56735636510452512E-9, -11.933116461089332),
> new
> Vector2D(2.56735636510452512E-9, -12.393225665247766),
> new
> Vector2D(2.56735636510452512E-9, -27.785625665247778),
> new
> Vector2D(4.26720030211, -27.785625665247778),
> new
> Vector2D(4.26720030211, -11.933116461089332));
> p.contains(w);
> }
> }
> {noformat}
> the exception thrown is:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:263)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:251)
> at
> org.apache.commons.math3.geometry.partitioning.AbstractRegion.contains(AbstractRegion.java:295)
> at Test.main(test.java:19)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1168) PolygonSet instantiation throws NullPointerException
[
https://issues.apache.org/jira/browse/MATH-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222496#comment-14222496
]
Luc Maisonobe commented on MATH-1168:
-
I was not able to reproduce the issue, neither with the current version after
fix for MATH-1162, nor when reverting to a version prior to the fix for
MATH-1162.
Could you check if it still occurs on your computer?
> PolygonSet instantiation throws NullPointerException
>
>
> Key: MATH-1168
> URL: https://issues.apache.org/jira/browse/MATH-1168
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: windows 8
>Reporter: gün alppay
>
> the following generates an exception
> {noformat}
> import org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet;
> import org.apache.commons.math3.geometry.euclidean.twod.Vector2D;
> class Test {
> public static void main(String[] args) {
> new PolygonsSet(1.0E-10,
> new Vector2D(-76.8095991248,
> -15.087601999),
> new Vector2D(-76.8095991245,
> -18.288001999),
> new Vector2D(-10.0583778834,
> -18.2880019979),
> new Vector2D(-10.0583778835,
> -15.0876019979),
> new Vector2D(-54.8639991264,
> -15.0876019984));
> }
> }
> {noformat}
> the exception is
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.math3.geometry.partitioning.BSPTree.fitToCell(BSPTree.java:301)
> at
> org.apache.commons.math3.geometry.partitioning.BSPTree.insertCut(BSPTree.java:159)
> at
> org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:333)
> at
> org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406)
> at
> org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406)
> at
> org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406)
> at
> org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406)
> at
> org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.verticesToTree(PolygonsSet.java:309)
> at
> org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.(PolygonsSet.java:156)
> at Test.main(test.java:6)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1166) BicubicInterpolation may have a bug
[ https://issues.apache.org/jira/browse/MATH-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222502#comment-14222502 ] Luc Maisonobe commented on MATH-1166: - If I understand correctly, the former BicubiSplineInterpolatingFunction which was deprecated by Hank would still be deprecated and we would have two different implementation, this new one and the piecewise one? I'm fine with this. > BicubicInterpolation may have a bug > --- > > Key: MATH-1166 > URL: https://issues.apache.org/jira/browse/MATH-1166 > Project: Commons Math > Issue Type: Bug >Reporter: Ajo Fod > Attachments: Draw.java, MATH-1166.patch, myimage.jpg > > > I plotted a random image with bicubic interpolation hoping to see something > like this: > http://en.wikipedia.org/wiki/Bicubic_interpolation > ... but instead I got something weird. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1166) BicubicInterpolation may have a bug
[
https://issues.apache.org/jira/browse/MATH-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222509#comment-14222509
]
Gilles commented on MATH-1166:
--
bq. BicubiSplineInterpolatingFunction \[...\] would still be deprecated
Correct.
bq. two different implementation, this new one and the piecewise one?
Yes.
The new implementation is also "piecewise". We should decide whether the names
should be changed to something more specific.
Also, there must be a way to build N-dimensional interpolation schemes, but the
current {{Tricubic...}} is tied to a buggy implementation, so it's better to
remove it, and perhaps think how a new one can be modular and use the different
alternative implementations at runtime...
> BicubicInterpolation may have a bug
> ---
>
> Key: MATH-1166
> URL: https://issues.apache.org/jira/browse/MATH-1166
> Project: Commons Math
> Issue Type: Bug
>Reporter: Ajo Fod
> Attachments: Draw.java, MATH-1166.patch, myimage.jpg
>
>
> I plotted a random image with bicubic interpolation hoping to see something
> like this:
> http://en.wikipedia.org/wiki/Bicubic_interpolation
> ... but instead I got something weird.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FILEUPLOAD-262) Processing of multipart/form-data request failed. null
[
https://issues.apache.org/jira/browse/FILEUPLOAD-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222744#comment-14222744
]
Kristian Rink commented on FILEUPLOAD-262:
--
Though I also thought this, I am unsure here. Part of our customers us a
JUpload based Java applet for uploading files in batch operation, and, watching
one of them via TeamViewer, it seems while uploading (n) files, the upload
always will transmit all(?) data and then just fail after. I attached part of
the applet debug log below. The length of data reported here
(getUploadLength()) on the client does match what the server seems to see. I've
also raised this question on a Jetty mailing list as I am unsure who's really
to blame here. Maybe additional yet empty form fields in the
multipart/form-data upload?
All along with this: I traced through the commons-fileupload sources and had a
look at FileUploadBase#parseRequest(...) and wonder whether this method could
or should be modified to not necessarily throw an Exception but rather to
return files that have successfully been transmitted all along with an error
message that something was wrong. In my test case, I tried uploading roughly
250 PDF files, each of them some megabytes in size. If this request fails,
maybe 220 of 250 files have been correctly transmitted, yet all of them get
wiped at the end of parseUploadRequest() in case of !successful ...
{code}
00277 16:12:01.705FileUploadThreadHTTP[DEBUG]
-ec5489tafxl\r\n
00277 16:12:01.705FileUploadThreadHTTP[DEBUG]
Content-Disposition: form-data; name="File0"; filename="...pdf"\r\n
00277 16:12:01.705FileUploadThreadHTTP[DEBUG] Content-Type:
application/acad\r\n
00277 16:12:01.705FileUploadThreadHTTP[DEBUG] \r\n
00278 16:12:01.705FileUploadThreadHTTP[DEBUG] --- fileheader
end
00279 16:12:01.705FileUploadThreadHTTP[DEBUG] in
UploadFileData.uploadFile (amount:5421811, getUploadLength(): 5421811)
00280 16:14:28.421FileUploadThreadHTTP[ERROR]
[wjhk.jupload2.exception.JUploadIOException:javax.net.ssl.SSLException]
Connection has been shutdown: javax.net.ssl.SSLException:
java.net.SocketException: Connection reset by peer: socket write error
(Upload-Vorgang wegen eines Fehlers gestoppt)
00281 16:14:28.421FileUploadThreadHTTP
wjhk.jupload2.exception.JUploadIOException: javax.net.ssl.SSLException:
Connection has been shutdown: javax.net.ssl.SSLException:
java.net.SocketException: Connection reset by peer: socket write error
00281 16:14:28.421FileUploadThreadHTTPat
wjhk.jupload2.upload.helper.HTTPConnectionHelper.dispose(HTTPConnectionHelper.java:410)
00281 16:14:28.421FileUploadThreadHTTPat
wjhk.jupload2.upload.FileUploadThreadHTTP.cleanRequest(FileUploadThreadHTTP.java:160)
00281 16:14:28.421FileUploadThreadHTTPat
wjhk.jupload2.upload.DefaultFileUploadThread.doNonChunkedUpload(DefaultFileUploadThread.java:716)
00281 16:14:28.421FileUploadThreadHTTPat
wjhk.jupload2.upload.DefaultFileUploadThread.doUpload(DefaultFileUploadThread.java:510)
00281 16:14:28.421FileUploadThreadHTTPat
wjhk.jupload2.upload.DefaultFileUploadThread.run(DefaultFileUploadThread.java:331)
00281 16:14:28.421FileUploadThreadHTTPCaused by:
javax.net.ssl.SSLException: Connection has been shutdown:
javax.net.ssl.SSLException: java.net.SocketException: Connection reset by peer:
socket write error
{code}
> Processing of multipart/form-data request failed. null
> --
>
> Key: FILEUPLOAD-262
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-262
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.2, 1.3.1
> Environment: Application: Jetty 9.1.4, Debian stable x86_64, Java
> 1.7.0_51
> Public access through reverse proxy (apache 2 2.2.22 + mod_proxy)
>Reporter: Kristian Rink
>Priority: Minor
> Labels: eof, exception, stacktrace
>
> Exposing an upload feature in an existing web application, I frequently see
> stack traces as the one posted below in my server log files. Additional notes:
> - The application runs in an embedded jetty (HTTP) behind an apache2
> mod_proxy reverse proxy (HTTPS).
> - These issues do not generally appear, I tried quite some uploading
> myself today and never managed to reproduce this behaviour even while
> uploading loads of files, large files and both together.
> - It does not seem to be generally tied to a particular browser; the
> users associated with these messages use Firefox, MSIE or Chrome.
> - Looking at network traffic (and t
