[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036053#comment-16036053
]
Gilles commented on NUMBERS-38:
---
Amey,
Thanks for taking this on.
However, the main interest here is not so much about coverage (that code is
called by other classes in the package) as it is to ensure that this particular
function produces the right values within some known tolerance.
Please correct me if I'm wrong, but it seems that your patch uses values
computed by the same code it is supposed to check.
We should resort to that only when there is no better alternative, which is
usually to compare with the results of another ("reference") library.
For example, you could execute a slightly modified version of the code found
[here|https://en.wikipedia.org/wiki/Lanczos_approximation] to get
independently computed values.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036042#comment-16036042
]
ASF GitHub Bot commented on NUMBERS-38:
---
Github user coveralls commented on the issue:
https://github.com/apache/commons-numbers/pull/5
[](https://coveralls.io/builds/11817098)
Coverage remained the same at 83.124% when pulling
**9b0367e153c51804d5022051b6722e1419f1b016 on ameyjadiye:master** into
**c2bfc4fbf8fe325eaf254c37128948b7644e5687 on apache:master**.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036041#comment-16036041
]
Amey Jadiye commented on NUMBERS-38:
PR is raised, please have a look
https://github.com/apache/commons-numbers/pull/5
Thanks,
Amey
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036040#comment-16036040
]
ASF GitHub Bot commented on NUMBERS-38:
---
GitHub user ameyjadiye opened a pull request:
https://github.com/apache/commons-numbers/pull/5
[NUMBERS-38]: Added Junit test cases for LanczosApproximation
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ameyjadiye/commons-numbers master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-numbers/pull/5.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 #5
commit 9b0367e153c51804d5022051b6722e1419f1b016
Author: Amey Jadiye
Date: 2017-06-03T18:42:19Z
[NUMBERS-38]: Added Junit test cases for LanczosApproximation
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036031#comment-16036031
]
Amey Jadiye commented on NUMBERS-38:
Ah, got it. will put some coverage around that, Thanks.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036028#comment-16036028
]
Gilles commented on NUMBERS-38:
---
There are no tests for the [value(double
x)|https://github.com/apache/commons-numbers/blob/d79edb264f71db3e88779efe2681fa8c48310c3c/commons-numbers-gamma/src/main/java/org/apache/commons/numbers/gamma/LanczosApproximation.java]
method.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IO-537) BOMInputStream shouldn't sort array of BOMs in-place
[
https://issues.apache.org/jira/browse/IO-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved IO-537.
-
Resolution: Fixed
Fix Version/s: 2.6
[~borowis],
Thank you for your report.
Fixed with commit d4f28d7ff397386b208823c577180938e15769d3.
Please verify and close.
Gary
> BOMInputStream shouldn't sort array of BOMs in-place
>
>
> Key: IO-537
> URL: https://issues.apache.org/jira/browse/IO-537
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.4, 2.5
> Environment: OS: Ubuntu 16.04
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
>Reporter: Borys Zibrov
> Labels: BOMInputStream
> Fix For: 2.6
>
>
> BOMInputStream constructor code sorts array of BOMs to distinguish between
> UTF-32LE and UTF-16LE:
> {code}
> public BOMInputStream(InputStream delegate, boolean include,
> ByteOrderMark... boms) {
> super(delegate);
> if (boms == null || boms.length == 0) {
> throw new IllegalArgumentException("No BOMs specified");
> }
> this.include = include;
> // Sort the BOMs to match the longest BOM first because some BOMs
> have the same starting two bytes.
> Arrays.sort(boms, ByteOrderMarkLengthComparator);
> this.boms = Arrays.asList(boms);
> }
> {code}
> The problem is the array is sorted in-place so that's 1) not expected by the
> caller 2) makes code not safe, if array is shared between threads and all
> create BOMInputStreams with single array of BOMs results are unpredictable.
> Instead a copy of the input array should be made and then sorted.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-136) FileUpload race condition with used with Jetty 6
[
https://issues.apache.org/jira/browse/FILEUPLOAD-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins closed FILEUPLOAD-136.
---
> FileUpload race condition with used with Jetty 6
>
>
> Key: FILEUPLOAD-136
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-136
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Running on Windows XP SP2 with Jetty 6 embedded and
> Firefox 2.0.0.4
>Reporter: Keith Kowalczykowski
>Assignee: Jochen Wiedmann
>Priority: Critical
> Attachments: FileUploadTest.zip, TestJetty.java
>
>
> When running commons file upload with Jetty 6, ServletFileUpload.parseRequest
> spins and never returns when the user clicks the "stop" button in their
> browser while an upload is in progress.
> Reproduction Steps:
> * Create a simple servlet / html form which accepts a file upload using
> commons file upload (or use the example code below).
> * Upload a sufficiently large file that you have time to click the stop
> button before the upload completes.
> * Observe that the thread is now stuck within file upload.
> Other Information:
> Using jstack, I was able to get the following trace of where it is blocking.
> It looks like it is on a read() call that file upload is making.
> at org/mortbay/jetty/HttpParser$Input.blockForContent(HttpParser.java:922)
> at org/mortbay/jetty/HttpParser$Input.read(HttpParser.java:897)
> at
> org/apache/commons/fileupload/MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:959)
> at
> org/apache/commons/fileupload/MultipartStream$ItemInputStream.close(MultipartStream.java:910)
> at org/apache/commons/fileupload/util/Streams.copy(Streams.java:119)
> at org/apache/commons/fileupload/util/Streams.copy(Streams.java:64)
> at
> org/apache/commons/fileupload/FileUploadBase.parseRequest(FileUploadBase.java:354)
> at
> org/apache/commons/fileupload/servlet/ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> at test/Main$1.handle(Main.java:43)
> at
> org/mortbay/jetty/handler/HandlerWrapper.handle(HandlerWrapper.java:139)
> at org/mortbay/jetty/Server.handle(Server.java:285)
> at org/mortbay/jetty/HttpConnection.handleRequest(HttpConnection.java:502)
> at
> org/mortbay/jetty/HttpConnection$RequestHandler.content(HttpConnection.java:835)
> at org/mortbay/jetty/HttpParser.parseNext(HttpParser.java:641)
> at org/mortbay/jetty/HttpParser.parseAvailable(HttpParser.java:208)
> at org/mortbay/jetty/HttpConnection.handle(HttpConnection.java:378)
> at
> org/mortbay/jetty/bio/SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org/mortbay/thread/BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> at jrockit/vm/RNI.c2java()V(Native Method)
> -- end of trac
> Originally I thought this was an issue with our code, however, I have since
> isolated it to a simple test case. Bellow is a class file called Main which
> when run will instantiate an instance of Jetty on port 8080 and an HTML
> document that will post a file upload to the servlet. When the stop button is
> pressed, you will see that the line "Starting processing" is printed, but
> neither the "Exception occured in processing" or "Processing completed" are
> printed. I have a full eclipse project (jars and all) on my machine that I
> was planning on uploading with this ticket, however, I don't see a way to
> attach a file. Therefore, I have copied and pasted the two files bellow. Let
> me know if you want the full project.
> === Main.java ===
> /**
> *
> */
> package test;
> import java.io.IOException;
> import java.util.List;
> import javax.servlet.ServletException;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> import org.apache.commons.fileupload.FileItem;
> import org.apache.commons.fileupload.disk.DiskFileItemFactory;
> import org.apache.commons.fileupload.servlet.ServletFileUpload;
> import org.mortbay.jetty.Handler;
> import org.mortbay.jetty.Server;
> import org.mortbay.jetty.handler.AbstractHandler;
> /**
> * @author Keith Kowalczykowski
> *
> */
> public class Main {
> public static void main(String[] args) {
> Handler handler = new AbstractHandler() {
> public void handle(String arg0, HttpServletRequest arg1,
> HttpServletResponse arg2, int arg3)
> throws IOException,
> ServletException
> {
> System.out.println("Starting processing");
> try
> {
>// Create a factory for disk-ba
[jira] [Closed] (FILEUPLOAD-170) problem in parseRequest method of
[ https://issues.apache.org/jira/browse/FILEUPLOAD-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed FILEUPLOAD-170. --- > problem in parseRequest method of > -- > > Key: FILEUPLOAD-170 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-170 > Project: Commons FileUpload > Issue Type: Bug > Environment: OS: fedora7 > IDE:Netbeans >Reporter: vaishali dolas >Assignee: Jochen Wiedmann > > I'm facing problem to build progressbar while file uploading > the code snippet is here > // Create a factory for disk-based file items > FileItemFactory factory = new DiskFileItemFactory(); > // Create a new file upload handler > ServletFileUpload upload = new ServletFileUpload(factory); > // Parse the request > List items = upload.parseRequest(request); > In items i'm always getting null -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-169) FileItemStreamImpl closes underlying stream on LimitedInputStream exception
[ https://issues.apache.org/jira/browse/FILEUPLOAD-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed FILEUPLOAD-169. --- > FileItemStreamImpl closes underlying stream on LimitedInputStream exception > --- > > Key: FILEUPLOAD-169 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-169 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Phillip Webb >Assignee: Jochen Wiedmann > Fix For: 1.2 > > Attachments: FILEUPLOAD-169.patch > > > FileUploadBase uses a LimitedInputStream to manage the fileSizeMax limit. If > the limit is exceeded the raiseError message closes the stream and throws a > FileSizeLimitExceededException. > Unfortunately the close method is called with true to close the underlying > MultipartStream. This means that additional calls to FileItemIteratorImpl > will fail as findNextItem() throws a MalformedStreamException. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-212) Insecure request size checking
[ https://issues.apache.org/jira/browse/FILEUPLOAD-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed FILEUPLOAD-212. --- > Insecure request size checking > -- > > Key: FILEUPLOAD-212 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-212 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.2.2 > Environment: Default configuration default environment. >Reporter: Damian Kolasa >Assignee: Thomas Neidhart >Priority: Critical > Labels: max_upload_size, resource_depletion, security > Fix For: 1.3 > > Attachments: FILEUPLOAD-212_fix.patch, FILEUPLOAD-212_test.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > In FileUploadBase there is an issue when checking for upload request size, > the check is based on presence of Content-Length header in request and FALSE > assumption that when present it will represent the actual request size. Using > this fact, attacker can supply request with defined Content-Length of 60 and > bypass file upload restrictions, which can lead to successful Resource > Depletion type attack. > IMHO by default file upload should return the LimitedInputStream > implementation for file upload. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-149) Intermittent file corruption on upload
[ https://issues.apache.org/jira/browse/FILEUPLOAD-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed FILEUPLOAD-149. --- > Intermittent file corruption on upload > -- > > Key: FILEUPLOAD-149 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-149 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.2 > Environment: Linux (CentOS) server; all client platforms and browsers >Reporter: F. Andy Seidl >Priority: Critical > > I have been struggling for several weeks trying to track down the root cause > of a sporadic file corruption problem using File Upload. I'm really stumped > at this point and welcome any suggestions as to avenues of debugging > pursuit. > Here's overview of the problem: > I have eight Linux (CentOS) servers all running the same web application--a > set of Java servlets using Resin as a servlet runner under Apache. All > servers were configured using the same script that installs jars, > config files, etc. > On three of the servers, File Upload works reliably. On five of the > servers, File Upload usually (but not always) leaves me with a corrupted file. > Corrupted files are always the correct length but contain a relatively small > percentage of scrambled bytes. I looked for obvious patterns like newlines > being altered or high-bit bytes being converted to or from UTF-8, but there > is no obvious (to me, anyway) pattern in the failure. > I have also tested with IE, FireFox, and Safari on both Windows and MacOS. > The issue appears to be independent of client browser and OS. > Looking at Java system properties, I notice that while the classpath and > bootclasspath have the same jars lists on all servers, they are not listed > in the same order (probably listed in directory order as the paths are > constructed by a script that inspects lib directories.) > Is anyone aware of classpath order dependencies that could break File > Upload? > Can anyone offer any suggestions about what *might* be breaking File Upload? > Or what other questions I should be asking? At the moment, I'm feeling > rather stumped. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-144) Parameters values are lost
[
https://issues.apache.org/jira/browse/FILEUPLOAD-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins closed FILEUPLOAD-144.
---
> Parameters values are lost
> --
>
> Key: FILEUPLOAD-144
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-144
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: JBoss 4 / XP / Servlet / both Firefox and IE
>Reporter: Vera Mickael
>Assignee: Jochen Wiedmann
>Priority: Critical
> Attachments: correction_with_test_cases_in_distribution.zip,
> MultipartStream.java, test.fileupload.zip, test.fileupload.zip
>
>
> When parsing a request with the streaming API, some parameters loose their
> values. I can easily reproduce the problem when a lot of parameters are
> submitted (about 400 in a table). My code is as follows :
> final FileItemStream itemStream = anItemIterator.next();
> final String fieldName = itemStream.getFieldName();
> System.out.print("Field " + fieldName);
> InputStream stream = itemStream.openStream();
> final String value = Streams.asString(stream, "UTF-8");
> The last statement sometimes returns a value and sometimes not. Sometimes I
> can retreive all parameters, sometimes I loose 3 or 4 parameters. I
> reproduced the problem on two computers. I have a very small application with
> a servlet of 69 lines that reproduces the problem, the project is attached to
> this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-174) Java.Lang.OutOfMemoryError while trying to post huge data with enctype="multipart/form-data"
[ https://issues.apache.org/jira/browse/FILEUPLOAD-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed FILEUPLOAD-174. --- > Java.Lang.OutOfMemoryError while trying to post huge data with > enctype="multipart/form-data" > > > Key: FILEUPLOAD-174 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-174 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.0 Final > Environment: Tomcat 5.0, JDK 1.4.2_09, SQLServer 2000, Struts 1.1, > Spring 1.2.4 >Reporter: Sambasiva Rao J >Assignee: Jochen Wiedmann >Priority: Critical > > 1: I am getting java.lang.OutOfMemoryError when the form in my jsp code is as > below. > > -- JSP code ? containing very huge data (hidden parameters) with file upload > attachment facility (). > > This is throwing OutOfMemoryError eventhough I am not attaching/uploading any > files. > 2:*** The same data is getting posted successfully if the form is submitted > with out > enctype="multipart/form-data" and without providing the attachment facility. > 3: Also if the data (number of items which are dynamic) is less, the form is > not throwing Out of memory exception even though we are submitting with > enctype="multipart/form-data" with file upload attachment fecility. > Please find the below log generated in Tomcat. > 2009-06-02 16:51:42 StandardWrapperValve[action]: Servlet.service() for > servlet action threw exception > java.lang.OutOfMemoryError > plese let me know if anybody came across this problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-233) Base64Decoder doesn't correctly implement RFC 4648
[ https://issues.apache.org/jira/browse/FILEUPLOAD-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed FILEUPLOAD-233. --- > Base64Decoder doesn't correctly implement RFC 4648 > -- > > Key: FILEUPLOAD-233 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-233 > Project: Commons FileUpload > Issue Type: Sub-task >Affects Versions: 1.3 >Reporter: Simone Tripodi >Priority: Critical > Fix For: 1.3 > > > r1458213 introduced an initial version of Base64Decoder test case which > clearly demonstrates that RFC 4648 is not correctly implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-261) Streaming API fails with file size < 8k
[
https://issues.apache.org/jira/browse/FILEUPLOAD-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins closed FILEUPLOAD-261.
---
> Streaming API fails with file size < 8k
>
>
> Key: FILEUPLOAD-261
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-261
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Luca Looz
>Priority: Critical
>
> I'm getting a SocketTimeoutException when using the Streaming API and
> uploading a file with a size smaller than 8k.
> {code}
> java.net.SocketTimeoutException
> at java.net.PlainSocketImpl.read(PlainSocketImpl.java:491)
> at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
> at
> java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:240)
> at java.io.PushbackInputStream.read(PushbackInputStream.java:185)
> at
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:999)
> at
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:903)
> at java.io.InputStream.read(InputStream.java:162)
> at
> org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)
> at
> org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)
> at
> org.apache.commons.fileupload.MultipartStream.readBodyData(MultipartStream.java:593)
> at
> org.apache.commons.fileupload.MultipartStream.discardBodyData(MultipartStream.java:617)
> at
> org.apache.commons.fileupload.MultipartStream.skipPreamble(MultipartStream.java:634)
> at
> org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:1023)
> at
> org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.(FileUploadBase.java:1003)
> at
> org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-165) Reading an uploaded file and returning that uploaded file in the exact same structure as the input file
[
https://issues.apache.org/jira/browse/FILEUPLOAD-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins closed FILEUPLOAD-165.
---
> Reading an uploaded file and returning that uploaded file in the exact same
> structure as the input file
> ---
>
> Key: FILEUPLOAD-165
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-165
> Project: Commons FileUpload
> Issue Type: Task
>Affects Versions: 1.2
> Environment: Windows XP Professional
>Reporter: Barry Barrios
>Assignee: Jochen Wiedmann
>Priority: Critical
> Fix For: 1.2.1
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I am using response.getWriter().write(new String(uploadItem.get() to write
> the uploaded input file. The code works pretty well except the output is very
> disorganized. I want the output to look exactly the same as the input file,
> in structure, the same space, the same columns, a perfect copy. However the
> output file, is scrammbled all together. What can be done to alter this code
> so that the input file looks like the output file.
> Sample Code Below:
> package de.herbstcampus.server;
> import java.io.IOException;
> import java.util.List;
> import javax.servlet.ServletException;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> import org.apache.commons.fileupload.FileItem;
> import org.apache.commons.fileupload.FileItemFactory;
> import org.apache.commons.fileupload.FileUploadException;
> import org.apache.commons.fileupload.disk.DiskFileItemFactory;
> import org.apache.commons.fileupload.servlet.ServletFileUpload;
> public class FileUploadServlet extends HttpServlet {
> private static final long serialVersionUID = 1156467149259077140L;
> protected void doPost(HttpServletRequest request,
> HttpServletResponse response) throws ServletException,
> IOException {
> FileItem uploadItem = getFileItem(request);
>
> /*
>* Note this must be 'text/html', otherwise the
> onSubmitComplete(...)
>* won't work properly and the browser may open a save dialog.
>*/
> response.setContentType("text/html");
>
> if (uploadItem == null) {
> response.getWriter().write("No data");
> return;
> } else {
> response.getWriter().write(new
> String(uploadItem.get()));
> }
> }
> @SuppressWarnings("unchecked")
> private FileItem getFileItem(HttpServletRequest request) {
> FileItemFactory factory = new DiskFileItemFactory();
> ServletFileUpload upload = new ServletFileUpload(factory);
> try {
> List items = upload.parseRequest(request);
>
> for (FileItem item: items) {
> if (!item.isFormField()
> &&
> "uploadFormElement".equals(item.getFieldName())) {
> return item;
> }
> }
> } catch (FileUploadException e) {
> return null;
> }
>
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-138) Fail to upload small files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed FILEUPLOAD-138. --- > Fail to upload small files > -- > > Key: FILEUPLOAD-138 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-138 > Project: Commons FileUpload > Issue Type: Bug > Environment: Tomcat 5.5 on Suse Linux 10.0 >Reporter: Martin Gröger >Assignee: Jochen Wiedmann >Priority: Critical > Fix For: 1.2.1 > > > Upload for very small files failed. The size (of failing) is lass than 58/59 > bytes. > It depends on the exact size of the keepRegion variable of the > MultipartStream. > Files less than this size contain no data at the target. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-228) (Servlet|Portlet)RequestContext#contentLength() must return request.getContentLength() if Content-length header is not available
[
https://issues.apache.org/jira/browse/FILEUPLOAD-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins closed FILEUPLOAD-228.
---
> (Servlet|Portlet)RequestContext#contentLength() must return
> request.getContentLength() if Content-length header is not available
>
>
> Key: FILEUPLOAD-228
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-228
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
>Priority: Blocker
> Fix For: 1.3
>
>
> As per subject, {{(Servlet|Portlet)RequestContext#contentLength()}} must
> return {{request.getContentLength()}} if _Content-length_ header is not
> available in request; actually it returns {{-1}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (FILEUPLOAD-167) Wrong .tmp file being passes by Internet Explorer (works fine in Firefox)
[ https://issues.apache.org/jira/browse/FILEUPLOAD-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins closed FILEUPLOAD-167. --- > Wrong .tmp file being passes by Internet Explorer (works fine in Firefox) > - > > Key: FILEUPLOAD-167 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-167 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.2 > Environment: windows/linux >Reporter: manish saroha >Assignee: Jochen Wiedmann >Priority: Blocker > > the tmp file name passed by the apache commons file upload library to my > struts action is wrong only in IE. > The .tmp file that is created in the temp directory in the tomcat server is > different to what gets passed through to the action class. > When using firefox , the correct .tmp file gets passed across. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (VFS-438) Please promote vfs-smb currently in the sandbox
[ https://issues.apache.org/jira/browse/VFS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036014#comment-16036014 ] Gary Gregory commented on VFS-438: -- Hi All, We welcome patches ;-) WRT https://github.com/hierynomus/smbj/blob/master/LICENSE_HEADER IANAL but I am not sure it is OK or not for us to link to a project that has a Copyright statement on top of the Apache license. That would be the first thing I would ask on legal@ Gary > Please promote vfs-smb currently in the sandbox > --- > > Key: VFS-438 > URL: https://issues.apache.org/jira/browse/VFS-438 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 > Environment: windows/unix >Reporter: Dan Tran > > Current smb provider in the sandbox is mature enough to proceed with > promotion out of sandbox for general use. > Detail discussion is here > http://apache-commons.680414.n4.nabble.com/Promote-vfs-cift-out-of-sandbox-td4636519.html > The sandbox also tests hookup to current test suite, all we need is to > provide a external URI using VFS test suite instructions. > There are currently 2 classloader specific failures > Tests in error: > testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): > code.ClassToLoad > testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): > code.sealed.AnotherClass > Tests run: 1745, Failures: 0, Errors: 2, Skipped: 0 > require cifs 1.3.17 with one line change at > SmbFileObject.java line number 227 to > if (e.getNtStatus() == SmbException.NT_STATUS_NO_SUCH_FILE) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035995#comment-16035995
]
Oliver Heger commented on CONFIGURATION-258:
Finally I came to reviewing this patch (sorry that it took so long). The patch
looks pretty good. Below are some comments:
* The name {{AbstractMapBasedConfiguration}} could be confused with
{{MapConfiguration}} (which is completely unrelated). Could there be a better
name describing what JSON and YAML have in common? (I have trouble with finding
one, too.)
* Is it possible to add the copy constructors supported by other hierarchical
configurations (that accept another hierarchical configuration as argument)?
* Please make sure that all source files have the Apache license header.
Ideally, even test data files should have headers if possible. (Not sure
whether JSON supports comments, I think YAML does.)
* We do not use @author tags any longer, so they should be removed.
* What is the json_helper.js file about?
* Some more comments, especially on newly introduced public methods, would be
good. But I could also add them later.
Thank you very much for your contribution.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035990#comment-16035990
]
Amey Jadiye commented on NUMBERS-38:
Hi,
I can see one test class here, do we expect more test cases here ?
https://github.com/apache/commons-numbers/blob/d79edb264f71db3e88779efe2681fa8c48310c3c/commons-numbers-gamma/src/test/java/org/apache/commons/numbers/gamma/LanczosApproximationTest.java
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (VFS-397) Add support for CIFS Directory content
[ https://issues.apache.org/jira/browse/VFS-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035984#comment-16035984 ] Christoph Obexer commented on VFS-397: -- There is smbj as noted in for example in https://issues.apache.org/jira/browse/VFS-438?focusedCommentId=16035980&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16035980 that would enable SMB2/3 support also > Add support for CIFS Directory content > -- > > Key: VFS-397 > URL: https://issues.apache.org/jira/browse/VFS-397 > Project: Commons VFS > Issue Type: New Feature >Reporter: Stounfree > Labels: cifs, commons-vfs, content, directory, listing > > Hello, > Could you please add support for listing CIFS Directory content. > Thanks in advance! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (VFS-438) Please promote vfs-smb currently in the sandbox
[ https://issues.apache.org/jira/browse/VFS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035980#comment-16035980 ] Christoph Obexer commented on VFS-438: -- There appears to be an Apache licensed implementation: https://github.com/hierynomus/smbj as noted on VFS-635 Please also note that SMBv1 as supported by jCIFS is considered bad by Microsoft: https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/ Maybe it's best to drop the current jCIFS based implementation from the sandbox and instead provide a smbj based implementation as a separate maven artifact. > Please promote vfs-smb currently in the sandbox > --- > > Key: VFS-438 > URL: https://issues.apache.org/jira/browse/VFS-438 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 > Environment: windows/unix >Reporter: Dan Tran > > Current smb provider in the sandbox is mature enough to proceed with > promotion out of sandbox for general use. > Detail discussion is here > http://apache-commons.680414.n4.nabble.com/Promote-vfs-cift-out-of-sandbox-td4636519.html > The sandbox also tests hookup to current test suite, all we need is to > provide a external URI using VFS test suite instructions. > There are currently 2 classloader specific failures > Tests in error: > testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): > code.ClassToLoad > testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests): > code.sealed.AnotherClass > Tests run: 1745, Failures: 0, Errors: 2, Skipped: 0 > require cifs 1.3.17 with one line change at > SmbFileObject.java line number 227 to > if (e.getNtStatus() == SmbException.NT_STATUS_NO_SUCH_FILE) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IO-537) BOMInputStream shouldn't sort array of BOMs in-place
[
https://issues.apache.org/jira/browse/IO-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Borys Zibrov updated IO-537:
Description:
BOMInputStream constructor code sorts array of BOMs to distinguish between
UTF-32LE and UTF-16LE:
{code}
public BOMInputStream(InputStream delegate, boolean include,
ByteOrderMark... boms) {
super(delegate);
if (boms == null || boms.length == 0) {
throw new IllegalArgumentException("No BOMs specified");
}
this.include = include;
// Sort the BOMs to match the longest BOM first because some BOMs have
the same starting two bytes.
Arrays.sort(boms, ByteOrderMarkLengthComparator);
this.boms = Arrays.asList(boms);
}
{code}
The problem is the array is sorted in-place so that's 1) not expected by the
caller 2) makes code not safe, if array is shared between threads and all
create BOMInputStreams with single array of BOMs results are unpredictable.
Instead a copy of the input array should be made and then sorted.
was:
BOMInputStream constructor code sorts array of BOMs to distinguish between
UTF-32LE and UTF-16LE:
{code}
public BOMInputStream(InputStream delegate, boolean include,
ByteOrderMark... boms) {
super(delegate);
if (boms == null || boms.length == 0) {
throw new IllegalArgumentException("No BOMs specified");
}
this.include = include;
// Sort the BOMs to match the longest BOM first because some BOMs have
the same starting two bytes.
Arrays.sort(boms, ByteOrderMarkLengthComparator);
this.boms = Arrays.asList(boms);
}
{code}
The problem is the array is sorted in-place so that's 1) not expected by the
caller 2) makes code not safe, if array is shared between threads and all
create BOMInputStreams with single array of BOMs results are unpredictable.
Instead the copy of the input array should be made and then sorted.
> BOMInputStream shouldn't sort array of BOMs in-place
>
>
> Key: IO-537
> URL: https://issues.apache.org/jira/browse/IO-537
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.4, 2.5
> Environment: OS: Ubuntu 16.04
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
>Reporter: Borys Zibrov
> Labels: BOMInputStream
>
> BOMInputStream constructor code sorts array of BOMs to distinguish between
> UTF-32LE and UTF-16LE:
> {code}
> public BOMInputStream(InputStream delegate, boolean include,
> ByteOrderMark... boms) {
> super(delegate);
> if (boms == null || boms.length == 0) {
> throw new IllegalArgumentException("No BOMs specified");
> }
> this.include = include;
> // Sort the BOMs to match the longest BOM first because some BOMs
> have the same starting two bytes.
> Arrays.sort(boms, ByteOrderMarkLengthComparator);
> this.boms = Arrays.asList(boms);
> }
> {code}
> The problem is the array is sorted in-place so that's 1) not expected by the
> caller 2) makes code not safe, if array is shared between threads and all
> create BOMInputStreams with single array of BOMs results are unpredictable.
> Instead a copy of the input array should be made and then sorted.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IO-537) BOMInputStream shouldn't sort array of BOMs in-place
[
https://issues.apache.org/jira/browse/IO-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Borys Zibrov updated IO-537:
Description:
BOMInputStream constructor code sorts array of BOMs to distinguish between
UTF-32LE and UTF-16LE:
{code}
public BOMInputStream(InputStream delegate, boolean include,
ByteOrderMark... boms) {
super(delegate);
if (boms == null || boms.length == 0) {
throw new IllegalArgumentException("No BOMs specified");
}
this.include = include;
// Sort the BOMs to match the longest BOM first because some BOMs have
the same starting two bytes.
Arrays.sort(boms, ByteOrderMarkLengthComparator);
this.boms = Arrays.asList(boms);
}
{code}
The problem is the array is sorted in-place so that's 1) not expected by the
caller 2) makes code not safe, if array is shared between threads and all
create BOMInputStreams with single array of BOMs results are unpredictable.
Instead the copy of the input array should be made and then sorted.
was:
BOMInputStream constructor code sorts array of BOMs to distinguish between
UTF-32LE and UTF-16LE:
{code}
public BOMInputStream(InputStream delegate, boolean include,
ByteOrderMark... boms) {
super(delegate);
if (boms == null || boms.length == 0) {
throw new IllegalArgumentException("No BOMs specified");
}
this.include = include;
// Sort the BOMs to match the longest BOM first because some BOMs have
the same starting two bytes.
Arrays.sort(boms, ByteOrderMarkLengthComparator);
this.boms = Arrays.asList(boms);
}
{code}
The problem is the array is sorted in-place so that's 1) not expected by the
caller 2) makes code not safe, if array is shared between threads and all
create BOMInputStreams with single array of BOMs results are unpredictable
> BOMInputStream shouldn't sort array of BOMs in-place
>
>
> Key: IO-537
> URL: https://issues.apache.org/jira/browse/IO-537
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.4, 2.5
> Environment: OS: Ubuntu 16.04
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
>Reporter: Borys Zibrov
> Labels: BOMInputStream
>
> BOMInputStream constructor code sorts array of BOMs to distinguish between
> UTF-32LE and UTF-16LE:
> {code}
> public BOMInputStream(InputStream delegate, boolean include,
> ByteOrderMark... boms) {
> super(delegate);
> if (boms == null || boms.length == 0) {
> throw new IllegalArgumentException("No BOMs specified");
> }
> this.include = include;
> // Sort the BOMs to match the longest BOM first because some BOMs
> have the same starting two bytes.
> Arrays.sort(boms, ByteOrderMarkLengthComparator);
> this.boms = Arrays.asList(boms);
> }
> {code}
> The problem is the array is sorted in-place so that's 1) not expected by the
> caller 2) makes code not safe, if array is shared between threads and all
> create BOMInputStreams with single array of BOMs results are unpredictable.
> Instead the copy of the input array should be made and then sorted.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IO-537) BOMInputStream shouldn't sort array of BOMs in-place
Borys Zibrov created IO-537:
---
Summary: BOMInputStream shouldn't sort array of BOMs in-place
Key: IO-537
URL: https://issues.apache.org/jira/browse/IO-537
Project: Commons IO
Issue Type: Improvement
Components: Streams/Writers
Affects Versions: 2.5, 2.4
Environment: OS: Ubuntu 16.04
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
Reporter: Borys Zibrov
BOMInputStream constructor code sorts array of BOMs to distinguish between
UTF-32LE and UTF-16LE:
{code}
public BOMInputStream(InputStream delegate, boolean include,
ByteOrderMark... boms) {
super(delegate);
if (boms == null || boms.length == 0) {
throw new IllegalArgumentException("No BOMs specified");
}
this.include = include;
// Sort the BOMs to match the longest BOM first because some BOMs have
the same starting two bytes.
Arrays.sort(boms, ByteOrderMarkLengthComparator);
this.boms = Arrays.asList(boms);
}
{code}
The problem is the array is sorted in-place so that's 1) not expected by the
caller 2) makes code not safe, if array is shared between threads and all
create BOMInputStreams with single array of BOMs results are unpredictable
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-399) OSGI package versions are overly pessimistic, except when they're overly optimisic
[ https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035916#comment-16035916 ] ASF GitHub Bot commented on COMPRESS-399: - Github user joehni commented on the issue: https://github.com/apache/commons-compress/pull/26 This is a Maven project and we follow Maven conventions. Anything that is processed by a Java compiler belongs into src/main/java (true for package-info.java files, not true for packageinfo files or package.html files). Anything else that should be collected in a jar file is a resource and belongs therefore into src/main/resources. The fact that you have to reconfigure the resources clearly demonstrates this. Nevertheless, these files will make our release process even more cumbersome if they are checked in as sources. The nature and content of the files identifies them clearly as something that can be generated. We might even be able to use the antrun plugin directly. If we put it into a profile and activate it based on file existence, we might even move it into commons-parent. > OSGI package versions are overly pessimistic, except when they're overly > optimisic > --- > > Key: COMPRESS-399 > URL: https://issues.apache.org/jira/browse/COMPRESS-399 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.14 >Reporter: Simon Spero >Priority: Minor > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The OSGI versions in the current distributions are not being correctly > generated. OSGI relies on package version numbers following semantic version > properly for correct resolution. > Current version numbers have been generated from the maven version. This has > lead to new minor version increases for packages that have no API changed; it > has also concealed major (breaking) changes to several packages since 1.0. > I have created two branches that address the issue. > Both add the bundle:baseline goal to the verify phase of the build. > The also both have packageinfo files added to every package, containing the > package version. These are picked up by the bundle manifest generator, and > are used if no explicit version is given in the "Export-Package" command. > Both branches bump the major version number for packages with any minor > changes to 2.0.0. This makes the bundle correct, but does not fix improper > import declarations made by users of earlier bundles. > One branch uses the version number from the oldest version that has no > changes when compared to HEAD, and which has not had any breaking changes > since 1.0.0. This will fail the build because version numbers should be > increasing, and may cause issues if an importing bundle uses a range that > requires an identical, but higher numbered version of the package > The other branch uses version 1.14.0 for all packages with no major changes. > A third alternative, which I didn't add, is to just set all packages be > version 1.14.0, and just bump major versions when required going forward. The > bulk of the major changes happened a good few versions back, so it's not as > bad as it could be. > If you have a preferred option, I can create a pull request on Github -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NUMBERS-42) Factory methods
Gilles created NUMBERS-42:
-
Summary: Factory methods
Key: NUMBERS-42
URL: https://issues.apache.org/jira/browse/NUMBERS-42
Project: Commons Numbers
Issue Type: New Feature
Reporter: Gilles
Priority: Trivial
Fix For: 1.0
Wherever applicable, provide {{of}} factory methods.
For example, in "complex.java":
{code}
public Complex ofCartesian(double re, double im) { /*... */ }
public Complex ofPolar(double r, double theta) { /*... */ }
{code}
To be considered: make the constructors private (or protected).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (NUMBERS-2) Potential performance issues in "ComplexUtils"
[ https://issues.apache.org/jira/browse/NUMBERS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated NUMBERS-2: - Description: See http://markmail.org/message/qnzauv65nb3gmz2h To be checked with JMH benchmarking code. Most of this class is concerned with arrays; I suggest to rename it "ComplexArrays". was: See http://markmail.org/message/qnzauv65nb3gmz2h To be checked with JMH benchmarking code. > Potential performance issues in "ComplexUtils" > -- > > Key: NUMBERS-2 > URL: https://issues.apache.org/jira/browse/NUMBERS-2 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Gilles >Priority: Minor > Labels: benchmark, performance > > See http://markmail.org/message/qnzauv65nb3gmz2h > To be checked with JMH benchmarking code. > Most of this class is concerned with arrays; I suggest to rename it > "ComplexArrays". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (NUMBERS-41) Utility class for angles in radians
[
https://issues.apache.org/jira/browse/NUMBERS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved NUMBERS-41.
---
Resolution: Done
commit 40fd2b4eb86b2f29e8141e08bd4f6338c79a4743
> Utility class for angles in radians
> ---
>
> Key: NUMBERS-41
> URL: https://issues.apache.org/jira/browse/NUMBERS-41
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Labels: api
> Fix For: 1.0
>
>
> I propose to create a {{PlaneAngleRadians}} utility class (in module
> "commons-numbers-angle").
> It's purely syntactic sugar, to shorten user calls when input and output are
> {{double}} values assumed to be in radians.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
