[jira] [Commented] (MATH-677) About package "transform"
[
https://issues.apache.org/jira/browse/MATH-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164212#comment-13164212
]
Sébastien Brisard commented on MATH-677:
{{FastFourierTransformer}} has been modified according to the above discussion
in revisions {{1211318}} and {{1211319}}.
* {{transform2()}} and {{inverseTransform2()}} have gone,
* constructors have been made private,
* two factory methods are provided {{create()}} and {{createUnitary}}.
This has a beneficial side effect: multi-dimensional FFT is no longer
restricted to the former {{transform2()}}/{{inverseTransform2()}} normalization
convention, as was previously the case.
> About package "transform"
> -
>
> Key: MATH-677
> URL: https://issues.apache.org/jira/browse/MATH-677
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Sébastien Brisard
>Priority: Minor
> Labels: api-change
> Fix For: 3.0
>
>
> Classes in package "o.a.c.m.transform" might require some changes in order to
> conform to goals set for the next major release.
> Some observations:
> # Exceptions
> ## Should remove use of deprecated "MathRuntimeException"
> ## Should throw more specific "Math...Exception" instances instead of
> standard IAE
> # Interface "RealTransformer" (and implementations) contain non-conformant
> method names (e.g. "inversetransform" instead of "inverseTransform").
> {color:red}Fixed in {{r1208293}}.{color}
> # "FastFourierTransformer":
> ## Methods "mdfft" and "verifyDataSet" take an argument of type "Object" (to
> allow an argument with an unspecified number of dimensions)
> ## The "RootsOfUnity" helper class could be moved to the "complex" package
> ## For clarity, multidimensional transform should be moved to a class of its
> own (and I also wonder whether the "MultiDimensionalComplexMatrix" name is
> not misleading)
> # "FastFourierTransformer", "FastSineTranformer" and "FastCosineTranformer"
> define public methods "tranform2" and "inversetransform2" but they are not
> part of an interface
> # Code uses variables that start with an uppercase. {color:red}Fixed,
> together with various formatting issues.{color}
> # "FastHadamardTransformer" contains illegible developer documentation (see
> Javadoc for protected method "fht"). {color:red}Tried to improve things in
> {{r1208986}}, but things are still a bit obscure. Besides, the link provided
> is broken. Will look into that.{color}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-18) Sanselan 0.97 - GIF Parser facilities return null values for xmp
[
https://issues.apache.org/jira/browse/SANSELAN-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-18.
--
Resolution: Invalid
There is definitely no XMP in that file:
$ exiv2 pr -p x -v /tmp/TestGIF.gif
File 1/1: /tmp/TestGIF.gif
/tmp/TestGIF.gif: No XMP data found in the file
Shotwell, Phatch, Irfanview, others, also failed.
As for writing XMP into a GIF, you should set PARAM_KEY_XMP_XML to the string
containing the XMP in the parameters you pass to Sanselan.writeImage().
Resolving this bug invalid.
> Sanselan 0.97 - GIF Parser facilities return null values for xmp
>
>
> Key: SANSELAN-18
> URL: https://issues.apache.org/jira/browse/SANSELAN-18
> Project: Commons Sanselan
> Issue Type: Bug
> Environment: Windows XP, JDK 1.5
>Reporter: Kelly Boettcher
> Attachments: TestGIF.gif
>
>
> When attempting to use both core Sanselan methods and GIFParser methods,
> attempts to retrieve XMP is resulting in null values. Example code below:
> File file;
> InputStream is;
> byte[] b;
> file = new File("C:/data/TestGIF.gif");
> is = new FileInputStream(file);
> b = new byte[is.available()];
> is.read(b);
> is.close();
>
> /* Testing the Sanselan getXMP */
> String xmp = Sanselan.getXmpXml(file); // returns null
> System.out.println(xmp);
>
> /* Testing the GIF image parser's xmp capabilities */
> GifImageParser parser = new GifImageParser();
> ByteSource bs = new ByteSourceArray(b);
> String existingXMP = parser.getXmpXml(bs, null); // returns null
> System.out.println(existingXMP);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-163) Unable to extract a file larger than 8GB from a Posix-format tar archive
[ https://issues.apache.org/jira/browse/COMPRESS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163814#comment-13163814 ] Stefan Bodewig commented on COMPRESS-163: - Sorry, I somehow missed the fact that we already had code that was parsing PAX headers. I agree the code should be corrected. > Unable to extract a file larger than 8GB from a Posix-format tar archive > > > Key: COMPRESS-163 > URL: https://issues.apache.org/jira/browse/COMPRESS-163 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: The tar archive used for testing was created by GNU tar, > but the problem will occur with any Posix-formatted tar file containing files > over 8GB in size. >Reporter: John Kodis >Priority: Minor > Fix For: 1.4 > > Attachments: > 0003-Allow-reading-large-files-from-Posix-tar-archives.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > An attempt to read a posix-format tar archive containing a file in excess of > 8^11 bytes in size will fail with a "Size out of range" illegal argument > exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-719) Strange deprecations in API
[ https://issues.apache.org/jira/browse/MATH-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163786#comment-13163786 ] Peter Bloem commented on MATH-719: -- Ah, so there is a mailing list. I guess I should have looked a little harder. I'll bring it up there. > Strange deprecations in API > --- > > Key: MATH-719 > URL: https://issues.apache.org/jira/browse/MATH-719 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0, 2.1, 2.2 >Reporter: Peter Bloem >Priority: Minor > Labels: api-change, deprecated > > Sorry if this doesn't belong here. I couldn't find any sort of mailing list > or other feedback mechanism on the website. > RealMatrix has some very odd deprecations. In particular inverse(), > getDeterminant() and isSingular(). The last has the message: > bq. Deprecated. as of release 2.0, replaced by the boolean negation of new > LUDecompositionImpl(m).getSolver().isNonSingular() > That's an implementation, not an interface. The whole point of having an > interface is that > * I can query whether a matrix is singular withou having to know about > LUDecompositions > * You guys can change the implementation of isSingular() if something better > pops up without us guys having to change our code. > I'm not using these methods now, because they're deprecated, but I've > basically recreated them in as static methods in a utility class. Wouldn't it > be much better to just put code from the deprecation message into the method > and remove the deprecation? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-719) Strange deprecations in API
[ https://issues.apache.org/jira/browse/MATH-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163737#comment-13163737 ] Gilles commented on MATH-719: - bq. Sorry if this doesn't belong here. Indeed, you'd better bring this kind of issue to the "dev" ML. :) The more so that there have been recent discussions about changing the matrix API and decisions ought to be made quite soon now. > Strange deprecations in API > --- > > Key: MATH-719 > URL: https://issues.apache.org/jira/browse/MATH-719 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0, 2.1, 2.2 >Reporter: Peter Bloem >Priority: Minor > Labels: api-change, deprecated > > Sorry if this doesn't belong here. I couldn't find any sort of mailing list > or other feedback mechanism on the website. > RealMatrix has some very odd deprecations. In particular inverse(), > getDeterminant() and isSingular(). The last has the message: > bq. Deprecated. as of release 2.0, replaced by the boolean negation of new > LUDecompositionImpl(m).getSolver().isNonSingular() > That's an implementation, not an interface. The whole point of having an > interface is that > * I can query whether a matrix is singular withou having to know about > LUDecompositions > * You guys can change the implementation of isSingular() if something better > pops up without us guys having to change our code. > I'm not using these methods now, because they're deprecated, but I've > basically recreated them in as static methods in a utility class. Wouldn't it > be much better to just put code from the deprecation message into the method > and remove the deprecation? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-719) Strange deprecations in API
Strange deprecations in API --- Key: MATH-719 URL: https://issues.apache.org/jira/browse/MATH-719 Project: Commons Math Issue Type: Bug Affects Versions: 2.2, 2.1, 2.0 Reporter: Peter Bloem Priority: Minor Sorry if this doesn't belong here. I couldn't find any sort of mailing list or other feedback mechanism on the website. RealMatrix has some very odd deprecations. In particular inverse(), getDeterminant() and isSingular(). The last has the message: bq. Deprecated. as of release 2.0, replaced by the boolean negation of new LUDecompositionImpl(m).getSolver().isNonSingular() That's an implementation, not an interface. The whole point of having an interface is that * I can query whether a matrix is singular withou having to know about LUDecompositions * You guys can change the implementation of isSingular() if something better pops up without us guys having to change our code. I'm not using these methods now, because they're deprecated, but I've basically recreated them in as static methods in a utility class. Wouldn't it be much better to just put code from the deprecation message into the method and remove the deprecation? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Kodis updated COMPRESS-16: --- Attachment: 0004-Prefer-octal-over-binary-size-representation.patch This one-character patch corrects an error in patch 0002. The expression representing the largest value that an eleven-digit octal number can contain must be forced to a long integer value, as otherwise it overflows the limits of an int and evaluates to zero. > unable to extract a TAR file that contains an entry which is 10 GB in size > -- > > Key: COMPRESS-16 > URL: https://issues.apache.org/jira/browse/COMPRESS-16 > Project: Commons Compress > Issue Type: Bug > Components: Archivers > Environment: I am using win xp sp3, but this should be platform > independent. >Reporter: Sam Smith > Attachments: > 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, > 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, > 0004-Prefer-octal-over-binary-size-representation.patch, ant-8GB-tar.patch, > patch-for-compress.txt > > > I made a TAR file which contains a file entry where the file is 10 GB in size. > When I attempt to extract the file using TarInputStream, it fails with the > following stack trace: > java.io.IOException: unexpected EOF with 24064 bytes unread > at > org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) > at > org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) > So, TarInputStream does not seem to support large (> 8 GB?) files. > Here is something else to note: I created that TAR file using TarOutputStream > , which did not complain when asked to write a 10 GB file into the TAR file, > so I assume that TarOutputStream has no file size limits? That, or does it > silently create corrupted TAR files (which would be the worst situation of > all...)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163681#comment-13163681 ] John Kodis edited comment on COMPRESS-16 at 12/6/11 4:29 PM: - Patch 0004 is a one-character change which corrects an error in patch 0002. The expression representing the largest value that an eleven-digit octal number can contain must be forced to a long integer value, as otherwise it overflows the limits of an int and evaluates to zero. was (Author: kodis): This one-character patch corrects an error in patch 0002. The expression representing the largest value that an eleven-digit octal number can contain must be forced to a long integer value, as otherwise it overflows the limits of an int and evaluates to zero. > unable to extract a TAR file that contains an entry which is 10 GB in size > -- > > Key: COMPRESS-16 > URL: https://issues.apache.org/jira/browse/COMPRESS-16 > Project: Commons Compress > Issue Type: Bug > Components: Archivers > Environment: I am using win xp sp3, but this should be platform > independent. >Reporter: Sam Smith > Attachments: > 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, > 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, > 0004-Prefer-octal-over-binary-size-representation.patch, ant-8GB-tar.patch, > patch-for-compress.txt > > > I made a TAR file which contains a file entry where the file is 10 GB in size. > When I attempt to extract the file using TarInputStream, it fails with the > following stack trace: > java.io.IOException: unexpected EOF with 24064 bytes unread > at > org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) > at > org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) > So, TarInputStream does not seem to support large (> 8 GB?) files. > Here is something else to note: I created that TAR file using TarOutputStream > , which did not complain when asked to write a 10 GB file into the TAR file, > so I assume that TarOutputStream has no file size limits? That, or does it > silently create corrupted TAR files (which would be the worst situation of > all...)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-163) Unable to extract a file larger than 8GB from a Posix-format tar archive
[ https://issues.apache.org/jira/browse/COMPRESS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163674#comment-13163674 ] John Kodis commented on COMPRESS-163: - Yes, the Pax headers are read in TarArchiveInputStream.paxHeaders. The pax header keyword=value pairs are first read into a hash table, and the table is subsequently scanned for values (namely, path, linkpath, uid, uname, gid, gname, and size) which are contained in a TarArchiveEntry. If found, the values in the Pax header hash table are used to supersede those in the current TarArchiveEntry. Also, on reviewing this section of code, I noticed that there's a minor error. The fields in the Pax header are stored as a length, a space character, the field name, an equals sign, the field value, and a newline character. So, for example "30 atime=1321711775.972059463\n". The code which extracts the keyword=value pairs ignores the length field and instead looks for the newline character to mark the end of the value field. This is okay for numeric values, but means that any path or linkpath values which contain a newline character will be misinterpreted. So although the code isn't strictly correct, it's unlikely to cause a problem in practice. > Unable to extract a file larger than 8GB from a Posix-format tar archive > > > Key: COMPRESS-163 > URL: https://issues.apache.org/jira/browse/COMPRESS-163 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: The tar archive used for testing was created by GNU tar, > but the problem will occur with any Posix-formatted tar file containing files > over 8GB in size. >Reporter: John Kodis >Priority: Minor > Fix For: 1.4 > > Attachments: > 0003-Allow-reading-large-files-from-Posix-tar-archives.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > An attempt to read a posix-format tar archive containing a file in excess of > 8^11 bytes in size will fail with a "Size out of range" illegal argument > exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-163) Unable to extract a file larger than 8GB from a Posix-format tar archive
[ https://issues.apache.org/jira/browse/COMPRESS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-163: Fix Version/s: (was: 1.3) 1.4 > Unable to extract a file larger than 8GB from a Posix-format tar archive > > > Key: COMPRESS-163 > URL: https://issues.apache.org/jira/browse/COMPRESS-163 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: The tar archive used for testing was created by GNU tar, > but the problem will occur with any Posix-formatted tar file containing files > over 8GB in size. >Reporter: John Kodis >Priority: Minor > Fix For: 1.4 > > Attachments: > 0003-Allow-reading-large-files-from-Posix-tar-archives.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > An attempt to read a posix-format tar archive containing a file in excess of > 8^11 bytes in size will fail with a "Size out of range" illegal argument > exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-163) Unable to extract a file larger than 8GB from a Posix-format tar archive
[ https://issues.apache.org/jira/browse/COMPRESS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163640#comment-13163640 ] Stefan Bodewig commented on COMPRESS-163: - I may be missing it, but is the code that actaully reads the PAX header and applies the size read available as well? > Unable to extract a file larger than 8GB from a Posix-format tar archive > > > Key: COMPRESS-163 > URL: https://issues.apache.org/jira/browse/COMPRESS-163 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: The tar archive used for testing was created by GNU tar, > but the problem will occur with any Posix-formatted tar file containing files > over 8GB in size. >Reporter: John Kodis >Priority: Minor > Fix For: 1.4 > > Attachments: > 0003-Allow-reading-large-files-from-Posix-tar-archives.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > An attempt to read a posix-format tar archive containing a file in excess of > 8^11 bytes in size will fail with a "Size out of range" illegal argument > exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FILEUPLOAD-203) Processing of multipart/form-data request failed. Async operation timed out
Processing of multipart/form-data request failed. Async operation timed out --- Key: FILEUPLOAD-203 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-203 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.1.1 Environment: AIX Reporter: Gopi K Swamy We are seeing the below exception when we do the load testing with our application. Please let us know any reason why this exception is appeared and also please let us know for any fixes needed to avoid this? [12-05-11-10:05:05] 495837912 [WebContainer : 6] ERROR com.ibm.dolphin.webengine.lifecycle.plugins.ServletManagerPlugin - servlet exception root cause: org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. Async operation timed out at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:384) at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:268) at org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:182) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:389) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:794) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:191) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1858) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:459) at javax.servlet.http.HttpServlet.service(HttpServlet.java:711) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at com.ibm.dolphin.webengine.lifecycle.plugins.ServletManagerPlugin.handleRequest(ServletManagerPlugin.java:117) at com.ibm.dolphin.webengine.lifecycle.LifecycleManager.processLifecycleRequest(LifecycleManager.java:225) at com.ibm.dolphin.webengine.servlet.DRLProxyServlet.service(DRLProxyServlet.java:90) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1657) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:939) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:502) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:179) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:864) at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305) at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:83) at com.ibm.ws.ssl.channel.impl.SSLReadServiceContext$SSLReadCompletedCallback.complete(SSLReadServiceContext.java:1784) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161) at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138) at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1604) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DIGESTER-153) Add Constructor support to ObjectCreateRule
[ https://issues.apache.org/jira/browse/DIGESTER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved DIGESTER-153. - Resolution: Fixed after having applied the Matt's patch that issue can be finally considered resolved :) Thanks Matt for the valuable help, I wouldn't know how to manage it without you! > Add Constructor support to ObjectCreateRule > --- > > Key: DIGESTER-153 > URL: https://issues.apache.org/jira/browse/DIGESTER-153 > Project: Commons Digester > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 3.2 > > Attachments: 153-ng.patch.txt > > > As shown in the past, the stack method of Digester has some [limitations > |http://markmail.org/message/wick27gw6n5weqk2] for fully support the > Constructors - it basically cannot use elements in the body as constructor > arguments - but it could support arguments extracted from attributes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-123) Redesign API for stability
[ https://issues.apache.org/jira/browse/JEXL-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-123: --- Description: 2.1 has shown it was very difficult to evolve the features without compromising stability, i.e. respecting the contract made by the API. 3.0 main goal is to make the API stable, making clear where the difference is between "using" Jexl and "customizing/improving" Jexl. Since it is targeted at new projects or at least very active ones, the development will not require Java 1.5 but will target Java6; i.e., the release may or may not include a Java 1.5 deployable version depending on need and contribution. was: 2.1 has shown it was very difficult to evolve the features without compromising stability, i.e. respecting the contract made by the API. 3.0 main goal is to make the API stable, making clear where the difference is between "using" Jexl and "customizing/improving" Jexl. Since it is targeted at new projects or at least very active ones, the deployment will require at least Java 1.6. Reworded deployment platform requirement > Redesign API for stability > -- > > Key: JEXL-123 > URL: https://issues.apache.org/jira/browse/JEXL-123 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Critical > Fix For: 3.0 > > > 2.1 has shown it was very difficult to evolve the features without > compromising stability, i.e. respecting the contract made by the API. > 3.0 main goal is to make the API stable, making clear where the difference is > between "using" Jexl and "customizing/improving" Jexl. > Since it is targeted at new projects or at least very active ones, the > development will not require Java 1.5 but will target Java6; i.e., the > release may or may not include a Java 1.5 deployable version depending on > need and contribution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-715) PascalDistribution returns wrong values of mean and variance
[
https://issues.apache.org/jira/browse/MATH-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-715.
Resolution: Fixed
Fix Version/s: 3.0
Fixed in {{r1210359}}.
> PascalDistribution returns wrong values of mean and variance
>
>
> Key: MATH-715
> URL: https://issues.apache.org/jira/browse/MATH-715
> Project: Commons Math
> Issue Type: Bug
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Fix For: 3.0
>
>
> The header of the Javadoc states that the random variable (say X) being
> represented by this {{o.a.c.m.distribution.PascalDistribution}} is the number
> of *failures*. The current Javadoc is slightly confusing, because it refers
> to the Wikipedia website, where the opposite convention is adopted (X is the
> number of *successes*) : different formulas therefore apply for the mean and
> variance of X. The javadoc should be made clearer, for example by inclusion
> of full formulas. Also the parameters differing from the Wikipedia reference
> should not have the same name
> * {{p}} is the probability of success in both cases: OK,
> * {{r}} is the number of failures in Wikipedia, but the number of successes
> in CM. This could be renamed (say) {{s}}.
> Finally, with the current notations of CM, the mean of X is given by
> {{mean(X) = r * (1 - p) / p}}, while the currently implemented formula is {{r
> * p / (1 - p)}}, which is actually the formula corresponding to the Wikipedia
> convention.
> The following piece of code shows that the current implementation is faulty
> {code:java}
> public class PascalDistributionDemo {
>public static void main(String[] args) {
>final int r = 10;
>final double p = 0.2;
>final int numTerms = 1000;
>final PascalDistribution distribution = new PascalDistribution(r, p);
>double mean = 0.;
>for (int k = numTerms - 1; k >= 0; k--) {
>mean += k * distribution.probability(k);
>}
>// The following prints 40.12
>System.out.println("Estimate of the mean = " + mean);
>// The following prints 2.5
>System.out.println("CM implementation = " +
> distribution.getNumericalMean());
>// The following prints 2.5
>System.out.println("r * p / (1 - p) = " + (r * p / (1 - p)));
>// The following prints 40.0
>System.out.println("r * (1 - p) / p = " + (r * (1 - p) / p));
>}
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
