[jira] [Resolved] (COMPRESS-265) PAX headers with "strange" names can not be written
[ https://issues.apache.org/jira/browse/COMPRESS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-265. - Resolution: Fixed fixed with svn revision 1570800 The bug only ever showed on Windows as the \ => / translation only happens there. Actually it didn't take any non-ASCII characters or very long names, a backslash in the wrong place was enough. > PAX headers with "strange" names can not be written > --- > > Key: COMPRESS-265 > URL: https://issues.apache.org/jira/browse/COMPRESS-265 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.7 >Reporter: Stefan Bodewig > Labels: tar > Fix For: 1.8 > > > as noted by [~paburk] in COMPRESS-203 if a non-ASCII character is > "7-bit-cleaned" to '\' this may lead to a file name for the PAX header that > looks like a directory name to TarArchiveEntry - which leads to a bug very > similar to COMPRESS-203. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (NET-516) parser problem occurs if the filename contains one or more characters of which the second byte of Shift-JIS code is 0x85
[ https://issues.apache.org/jira/browse/NET-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908982#comment-13908982 ] Sebb commented on NET-516: -- Thanks. However I have tried listing the site files, and I don't see any problem, so unfortunately it does not help with testing the changes. > parser problem occurs if the filename contains one or more characters of > which the second byte of Shift-JIS code is 0x85 > > > Key: NET-516 > URL: https://issues.apache.org/jira/browse/NET-516 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.0 > Environment: windows >Reporter: Asha K S > Fix For: 2.0 > > Attachments: FTPSample.java, IIS FTP Files.zip, > listfilesStreamBytes.txt, notworking.png, working.png > > > Problem occurs if the filename contains one or more characters of which the > second byte of Shift-JIS code is 0x85, on a windows Japanese machine when > listing file names from IIS FTP server. > This was working fine in commons-net-1.4.0.jar . > [This relates to the NTFTPEntryParser] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (MATH-1101) QR and Rank-revealing QR fail to find a least-squares solution
[
https://issues.apache.org/jira/browse/MATH-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908980#comment-13908980
]
Roman Werpachowski commented on MATH-1101:
--
In this case the description of QRDecomposition.getSolver() is misleading,
since it says:
"Get a solver for finding the A × X = B solution in least square sense." (same
for RRQRDecomposition).
Also the documentation in
http://commons.apache.org/proper/commons-math/userguide/linear.html says that
the QR decomposition method can handle any matrix and return a least squares
solution.
If the QRDecomposition works better with non-zero threshold, then it may be
worth considering changing the default threshold value from zero, since the
current default behaviour is not what the user might expect based on the
documentation.
Finally, it is always possible to have a least squares solution of || A * x - b
||^2, because the norm is bounded from below by zero and diverges to infinity
as the norm of x goes to infinity. The solution may not be unique though. Also
note that the SVD solver returns a much more sensible solution, which minimizes
|| A * x - b ||^2.
> QR and Rank-revealing QR fail to find a least-squares solution
> --
>
> Key: MATH-1101
> URL: https://issues.apache.org/jira/browse/MATH-1101
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Roman Werpachowski
> Labels: solver
> Attachments: math-1101-bug.java
>
>
> QR and RRQR (rank-revealing) algorithms fail to find a least-squares solution
> in some cases.
> The following code:
> final RealMatrix A = new BlockRealMatrix(3, 3);
> A.setEntry(0, 0, 1);
> A.setEntry(0, 1, 6);
> A.setEntry(0, 2, 4);
> A.setEntry(1, 0, 2);
> A.setEntry(1, 1, 4);
> A.setEntry(1, 2, -1);
> A.setEntry(2, 0, -1);
> A.setEntry(2, 1, 2);
> A.setEntry(2, 2, 5);
> final RealVector b = new ArrayRealVector(new double[]{5, 6, 1});
> final QRDecomposition qrDecomposition = new QRDecomposition(A);
> final RRQRDecomposition rrqrDecomposition = new RRQRDecomposition(A);
> final SingularValueDecomposition svd = new
> SingularValueDecomposition(A);
> final RealVector xQR = qrDecomposition.getSolver().solve(b);
> System.out.printf("QR solution: %s\n", xQR.toString());
> final RealVector xRRQR = rrqrDecomposition.getSolver().solve(b);
> System.out.printf("RRSQ solution: %s\n", xRRQR.toString());
> final RealVector xSVD = svd.getSolver().solve(b);
> System.out.printf("SVD solution: %s\n", xSVD.toString());
> produces
> QR solution: {-3,575,212,378,628,897; 1,462,586,882,166,368;
> -1,300,077,228,592,326.5}
> RRSQ solution: {5,200,308,914,369,308; -2,127,399,101,332,898;
> 1,891,021,423,407,021}
> SVD solution: {0.5050344462; 1.0206677266; -0.2405935347}
> Showing that QR and RRQR algorithms fail to find the least-squares solution.
> This can also be verified by calculating the dot product between columns of A
> and A*x - b:
> // x = xQR, xRRQR or xSVD
> final RealVector r = A.operate(x).subtract(b);
> for (int i = 0; i < x.getDimension(); ++i) {
> final RealVector columnVector = A.getColumnVector(i);
> assertEquals(name, 0.0, r.dotProduct(columnVector), tolerance);
> }
> Only SVD method passes this test with decent tolerance (1E-14 or so).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Attachment: ntpServer.patch.txt > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > Attachments: ntpServer.patch.txt > > > I've implemented a minimal NTP server that doesn't actually adjust the time > but responds to NTP datagram requests with info filled out using the current > clock time to be be used for debugging and testing. At minimum it can be used > as a test harness to test the NTPClient class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation and test provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Attachment: (was: ntpServer.patch.txt) > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > > I've implemented a minimal NTP server that doesn't actually adjust the time > but responds to NTP datagram requests with info filled out using the current > clock time to be be used for debugging and testing. At minimum it can be used > as a test harness to test the NTPClient class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation and test provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Attachment: ntpServer.patch.txt > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > Attachments: ntpServer.patch.txt > > > I've implemented a minimal NTP server that doesn't actually adjust the time > but responds to NTP datagram requests with info filled out using the current > clock time to be be used for debugging and testing. At minimum it can be used > as a test harness to test the NTPClient class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation and test provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Attachment: (was: ntpServer.patch.txt) > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > Attachments: ntpServer.patch.txt > > > I've implemented a minimal NTP server that doesn't actually adjust the time > but responds to NTP datagram requests with info filled out using the current > clock time to be be used for debugging and testing. At minimum it can be used > as a test harness to test the NTPClient class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation and test provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Description: I've implemented a minimal NTP server that doesn't actually adjust the time but responds to NTP datagram requests with info filled out using the current clock time to be be used for debugging and testing. At minimum it can be used as a test harness to test the NTPClient class. Added appropriate junit test. The SimpleNTPServer class complements the existing NtpClient class. Implementation and test provided in attached patch file. was: I've implemented a Simple UDP NTP server that can be used for debugging and testing. At minimum it can be used as a test harness to test the NTPClient class. Added appropriate junit test. The SimpleNTPServer class complements the existing NtpClient class. Implementation and test provided in attached patch file. > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > Attachments: ntpServer.patch.txt > > > I've implemented a minimal NTP server that doesn't actually adjust the time > but responds to NTP datagram requests with info filled out using the current > clock time to be be used for debugging and testing. At minimum it can be used > as a test harness to test the NTPClient class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation and test provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (NET-516) parser problem occurs if the filename contains one or more characters of which the second byte of Shift-JIS code is 0x85
[ https://issues.apache.org/jira/browse/NET-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908586#comment-13908586 ] pavan commented on NET-516: --- I have somehow managed to create a public ftp site and hosted it at ftp://commonsnet.ftpstream.com/. But i am unable to find a way to set any japanese charset/encoding. I will mail you the site credentials > parser problem occurs if the filename contains one or more characters of > which the second byte of Shift-JIS code is 0x85 > > > Key: NET-516 > URL: https://issues.apache.org/jira/browse/NET-516 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.0 > Environment: windows >Reporter: Asha K S > Fix For: 2.0 > > Attachments: FTPSample.java, IIS FTP Files.zip, > listfilesStreamBytes.txt, notworking.png, working.png > > > Problem occurs if the filename contains one or more characters of which the > second byte of Shift-JIS code is 0x85, on a windows Japanese machine when > listing file names from IIS FTP server. > This was working fine in commons-net-1.4.0.jar . > [This relates to the NTFTPEntryParser] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SANDBOX-462) Refactoring of AccessibleObjectsRegistry
[ https://issues.apache.org/jira/browse/SANDBOX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908570#comment-13908570 ] Andre Diermann commented on SANDBOX-462: Hi Benedikt, any hints how to check the rules and format the code already on my site? Do you have a code style config for your IDE? Do you run checkstyle locally? Currently I don't even know what I messed up exactly :-/ So sorry for the additional effort any many thanks for applying the patch. :-) I will now continue with the "bigger" changes. See you, André > Refactoring of AccessibleObjectsRegistry > > > Key: SANDBOX-462 > URL: https://issues.apache.org/jira/browse/SANDBOX-462 > Project: Commons Sandbox > Issue Type: Improvement > Components: BeanUtils2 >Reporter: Andre Diermann >Priority: Minor > Attachments: Commons-BeanUtils2-462#1.patch > > > Summary: > The AccessibleObjectsRegistry class provides two get methods, while one is a > convenient method for the other. > Both methods take one conditional parameter, boolean exact, and the actual > get method is very long, which makes it somehow complex to understand. > Suggestion: > What could be improved IMHO: > - Instead of using conditional methods, like get(boolean > doSomethingSpecialIfTrue, ...), it is more convenient to provide dedicated > methods like getSomething() and getAnotherThing(). > - In this regard the difference between an exact or, let's call it, matching > descriptor should be expressed through inheritance rather than object > allocation (= expressing it by a field boolean exact). > - The very long get method should be refined > - Another very minor issue is the naming of the paramTypes field within the > inner AccessibleObjectDescriptor class, which I would suggest to rename to > parameterTypes to fit the naming of the other occurrences. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (COMPRESS-264) ZIP reads correctly with commons-compress 1.6, gives NUL bytes in 1.7
[
https://issues.apache.org/jira/browse/COMPRESS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Nieder closed COMPRESS-264.
Thanks! Confirmed - the fix works well.
> ZIP reads correctly with commons-compress 1.6, gives NUL bytes in 1.7
> -
>
> Key: COMPRESS-264
> URL: https://issues.apache.org/jira/browse/COMPRESS-264
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.7
> Environment: Ubuntu precise
>Reporter: Jonathan Nieder
>Priority: Minor
> Fix For: 1.8
>
>
> When running the code below, commons-compress 1.6 writes:
> Content of test.txt:
> data
> By comparison, commons-compress 1.7 writes
> Content of test.txt:
> ^@^@^@^@^@
> package com.example.jrn;
> import org.apache.commons.compress.archivers.zip.ZipArchiveEntry;
> import org.apache.commons.compress.archivers.zip.ZipArchiveInputStream;
> import java.io.ByteArrayInputStream;
> import java.io.IOException;
> import java.lang.System;
> /**
> * Hello world!
> *
> */
> public class App {
> public static void main(String[] args) {
> byte[] zip = {
>(byte)0x50, (byte)0x4b, (byte)0x03, (byte)0x04, (byte)0x0a, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x03, (byte)0x7b,
>(byte)0xd1, (byte)0x42, (byte)0x82, (byte)0xc5, (byte)0xc1, (byte)0xe6,
>(byte)0x05, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x05, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x08, (byte)0x00, (byte)0x1c, (byte)0x00,
>(byte)0x74, (byte)0x65, (byte)0x73, (byte)0x74, (byte)0x2e, (byte)0x74,
>(byte)0x78, (byte)0x74, (byte)0x55, (byte)0x54, (byte)0x09, (byte)0x00,
>(byte)0x03, (byte)0x56, (byte)0x62, (byte)0xbf, (byte)0x51, (byte)0x2a,
>(byte)0x63, (byte)0xbf, (byte)0x51, (byte)0x75, (byte)0x78, (byte)0x0b,
>(byte)0x00, (byte)0x01, (byte)0x04, (byte)0x01, (byte)0xff, (byte)0x01,
>(byte)0x00, (byte)0x04, (byte)0x88, (byte)0x13, (byte)0x00, (byte)0x00,
>(byte)0x64, (byte)0x61, (byte)0x74, (byte)0x61, (byte)0x0a, (byte)0x50,
>(byte)0x4b, (byte)0x01, (byte)0x02, (byte)0x1e, (byte)0x03, (byte)0x0a,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x03,
>(byte)0x7b, (byte)0xd1, (byte)0x42, (byte)0x82, (byte)0xc5, (byte)0xc1,
>(byte)0xe6, (byte)0x05, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x05,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x08, (byte)0x00, (byte)0x18,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x01,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0xa0, (byte)0x81, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x74, (byte)0x65, (byte)0x73,
>(byte)0x74, (byte)0x2e, (byte)0x74, (byte)0x78, (byte)0x74, (byte)0x55,
>(byte)0x54, (byte)0x05, (byte)0x00, (byte)0x03, (byte)0x56, (byte)0x62,
>(byte)0xbf, (byte)0x51, (byte)0x75, (byte)0x78, (byte)0x0b, (byte)0x00,
>(byte)0x01, (byte)0x04, (byte)0x01, (byte)0xff, (byte)0x01, (byte)0x00,
>(byte)0x04, (byte)0x88, (byte)0x13, (byte)0x00, (byte)0x00, (byte)0x50,
>(byte)0x4b, (byte)0x05, (byte)0x06, (byte)0x00, (byte)0x00, (byte)0x00,
>(byte)0x00, (byte)0x01, (byte)0x00, (byte)0x01, (byte)0x00, (byte)0x4e,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x47, (byte)0x00, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)00
> };
> ByteArrayInputStream bin = new ByteArrayInputStream(zip);
> try {
> ZipArchiveInputStream in = new ZipArchiveInputStream(bin);
> try {
> while (true) {
> ZipArchiveEntry entry = in.getNextZipEntry();
> if (entry == null) {
> break;
> }
> byte[] buf = new byte[(int) entry.getSize()];
> in.read(buf);
> System.out.println("Content of " + entry.getName() + ":");
> System.out.write(buf);
> }
> } finally {
> in.close();
> }
> } catch (IOException e) {
> System.err.println("IOException: " + e);
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (EXEC-84) CommandLine implementing Serializeable
[ https://issues.apache.org/jira/browse/EXEC-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved EXEC-84. -- Resolution: Implemented Fix Version/s: 1.2 In version 1.2, the class CommandLine implements Serializable. > CommandLine implementing Serializeable > -- > > Key: EXEC-84 > URL: https://issues.apache.org/jira/browse/EXEC-84 > Project: Commons Exec > Issue Type: New Feature > Environment: all >Reporter: Stefan Richter > Fix For: 1.2 > > > In my java application i have to execute various CommandLine applications. > Now i want to send these applications as Actors to a remote machine. The most > natural would be to have the CommandLine object of apache exec in the Actor > message. However, the CommandLine does not implement the Serializable > interface. Is there any problem tagging the CommandLine object as > Serializable? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COMPRESS-266) Allow parameters for compression methods to be configured when creating 7z archives
[ https://issues.apache.org/jira/browse/COMPRESS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-266: Labels: 7z (was: ) > Allow parameters for compression methods to be configured when creating 7z > archives > --- > > Key: COMPRESS-266 > URL: https://issues.apache.org/jira/browse/COMPRESS-266 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.6, 1.7 >Reporter: Stefan Bodewig > Labels: 7z > Fix For: 1.8 > > > This is especially useful for LZMA2 where a dictionary size bigger than the > default may lead to improved compression ratios. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (COMPRESS-266) Allow parameters for compression methods to be configured when creating 7z archives
Stefan Bodewig created COMPRESS-266: --- Summary: Allow parameters for compression methods to be configured when creating 7z archives Key: COMPRESS-266 URL: https://issues.apache.org/jira/browse/COMPRESS-266 Project: Commons Compress Issue Type: New Feature Components: Archivers Affects Versions: 1.7, 1.6 Reporter: Stefan Bodewig Fix For: 1.8 This is especially useful for LZMA2 where a dictionary size bigger than the default may lead to improved compression ratios. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (POOL-202) GenericKeyedObjectPool.close() can interfere with evict(); eviction[Key]Iterator is not consistently synched.
[ https://issues.apache.org/jira/browse/POOL-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated POOL-202: - Fix Version/s: 2.0 > GenericKeyedObjectPool.close() can interfere with evict(); > eviction[Key]Iterator is not consistently synched. > - > > Key: POOL-202 > URL: https://issues.apache.org/jira/browse/POOL-202 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Sebb > Fix For: 2.0 > > > As far as I can tell, calling close during an evict() run can cause problems, > because close() sets the eviction[Key]Iterator fields to null. > I suspect close() and evict() should be mutually exclusive. > Maybe close does not need to nullify the eviction[Key]Iterator fields, but > there's probably other mutually incompatible behaviour. > Or maybe the fields should be nulled in startEvictor. > Also, the fields eviction[Key]Iterator aren't volatile and aren't always > accessed under the same lock so might not be safely published. > That would be solved by moving the nulling to startEvictor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (POOL-205) GKOP - inconsistent synchronisation of poolKeyList
[ https://issues.apache.org/jira/browse/POOL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated POOL-205: - Fix Version/s: 2.0 > GKOP - inconsistent synchronisation of poolKeyList > -- > > Key: POOL-205 > URL: https://issues.apache.org/jira/browse/POOL-205 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Sebb > Fix For: 2.0 > > > poolKeyList is an ArrayList - which is not thread-safe. > Updates are performed whilst holding the keyLock.writeLock. > However, the list is read in evict() without using the same lock, so there's > a potential for evict() to see stale or inconsistent state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (POOL-206) GOP/GKOP close() - incorrect behaviour with evict() ?
[ https://issues.apache.org/jira/browse/POOL-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated POOL-206: - Fix Version/s: 2.0 > GOP/GKOP close() - incorrect behaviour with evict() ? > - > > Key: POOL-206 > URL: https://issues.apache.org/jira/browse/POOL-206 > Project: Commons Pool > Issue Type: Bug >Reporter: Sebb > Fix For: 2.0 > > > GOP/GKOP close() methods close the pool before stopping the evictor; that > seems wrong. > The evict() method calls assertOpen() so the evictor thread should be stopped > before closing the pool. > Also, the evictor thread should probably be allowed to complete if currently > active. > Not sure about calling clear() before the evictor is cancelled; should > perhaps be run afterwards? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (POOL-221) PooledObject.state does not need to be volatile
[ https://issues.apache.org/jira/browse/POOL-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated POOL-221: - Fix Version/s: 2.0 > PooledObject.state does not need to be volatile > --- > > Key: POOL-221 > URL: https://issues.apache.org/jira/browse/POOL-221 > Project: Commons Pool > Issue Type: Bug >Reporter: Sebb > Fix For: 2.0 > > > The field PooledObject.state is volatile, but is also always accessed in a > synchronised method except in toString(). > The volatile modifier is not cost free; it might be better to remove it and > add a small synch. block in toString(). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COMPRESS-261) Unable to set SevenZOutputFile.setContentCompression() per SevenZArchiveEntry
[
https://issues.apache.org/jira/browse/COMPRESS-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-261:
Issue Type: Improvement (was: Bug)
> Unable to set SevenZOutputFile.setContentCompression() per SevenZArchiveEntry
> -
>
> Key: COMPRESS-261
> URL: https://issues.apache.org/jira/browse/COMPRESS-261
> Project: Commons Compress
> Issue Type: Improvement
>Affects Versions: 1.7
> Environment: xz-1.4.jar is used as LMZA lib
>Reporter: Peter Sauer
>Priority: Minor
> Fix For: 1.8
>
>
> I am unable to set the compression method per archive entry. In my example I
> try to switch from LZMA2 to COPY for the second entry. But 7zip says that
> both entry has COPY as compression method.
> {code}
> public static void main(String args[]) throws Exception {
> String t = "Das ist ein kleiner Test!";
> SevenZOutputFile sevenZOutput = new SevenZOutputFile(new File(
> "c:/tmp/test.7z"));
> sevenZOutput.setContentCompression(SevenZMethod.LZMA2);
> SevenZArchiveEntry entry = new SevenZArchiveEntry();
> entry.setName("test");
> sevenZOutput.putArchiveEntry(entry);
> sevenZOutput.write(t.getBytes());
> sevenZOutput.closeArchiveEntry();
>sevenZOutput.setContentCompression(SevenZMethod.COPY);
> entry = new SevenZArchiveEntry();
> entry.setName("test2");
> sevenZOutput.putArchiveEntry(entry);
> sevenZOutput.write(t.getBytes());
> sevenZOutput.closeArchiveEntry();
> sevenZOutput.finish();
> sevenZOutput.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (COMPRESS-231) Add support for multpart 7z archives
[ https://issues.apache.org/jira/browse/COMPRESS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-231: Issue Type: Improvement (was: Bug) > Add support for multpart 7z archives > > > Key: COMPRESS-231 > URL: https://issues.apache.org/jira/browse/COMPRESS-231 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Reporter: Leon Blakey > Labels: 7z > > Has support for multipart 7z archives been discussed? Compress would only > need to cat the files together. > In terms of actual implementation I tried to take a stab at it myself but > SevenZFile relies on RandomAccessFile which complicates things like > readFully() with a buffer that spans 2 files. I stopped when it started > getting complex and was wondering what would be the "compress" way to do it -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COMPRESS-265) PAX headers with "strange" names can not be writtem
[ https://issues.apache.org/jira/browse/COMPRESS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-265: Description: as noted by [~paburk] in COMPRESS-203 if a non-ASCII character is "7-bit-cleaned" to '\' this may lead to a file name for the PAX header that looks like a directory name to TarArchiveEntry - which leads to a bug very similar to COMPRESS-203. (was: as noted by [~paburk] in COMPRESS-203 if a non-ASCII character is "z-bit-cleaned" to \ this may lead to a file name for the PAX header that looks like a directory name to TarArchiveEntry - which leads to a bug very similar to COMPRESS-203.) > PAX headers with "strange" names can not be writtem > --- > > Key: COMPRESS-265 > URL: https://issues.apache.org/jira/browse/COMPRESS-265 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.7 >Reporter: Stefan Bodewig > Labels: tar > Fix For: 1.8 > > > as noted by [~paburk] in COMPRESS-203 if a non-ASCII character is > "7-bit-cleaned" to '\' this may lead to a file name for the PAX header that > looks like a directory name to TarArchiveEntry - which leads to a bug very > similar to COMPRESS-203. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COMPRESS-265) PAX headers with "strange" names can not be written
[ https://issues.apache.org/jira/browse/COMPRESS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-265: Summary: PAX headers with "strange" names can not be written (was: PAX headers with "strange" names can not be writtem) > PAX headers with "strange" names can not be written > --- > > Key: COMPRESS-265 > URL: https://issues.apache.org/jira/browse/COMPRESS-265 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.7 >Reporter: Stefan Bodewig > Labels: tar > Fix For: 1.8 > > > as noted by [~paburk] in COMPRESS-203 if a non-ASCII character is > "7-bit-cleaned" to '\' this may lead to a file name for the PAX header that > looks like a directory name to TarArchiveEntry - which leads to a bug very > similar to COMPRESS-203. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Attachment: ntpServer.patch.txt > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > Attachments: ntpServer.patch.txt > > > I've implemented a Simple UDP NTP server that can be used for debugging and > testing. At minimum it can be used as a test harness to test the NTPClient > class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation and test provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Attachment: (was: ntpServer.patch.txt) > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > > I've implemented a Simple UDP NTP server that can be used for debugging and > testing. At minimum it can be used as a test harness to test the NTPClient > class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation and test provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (EXEC-84) CommandLine implementing Serializeable
[ https://issues.apache.org/jira/browse/EXEC-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908377#comment-13908377 ] Sebb commented on EXEC-84: -- Supporting serializable requires a lot more work than just adding "implements Serializable". It should not be added without carefully evaluating the disadvantages. AFAICT, your use case could easily be solved by writing your own Serializable class. > CommandLine implementing Serializeable > -- > > Key: EXEC-84 > URL: https://issues.apache.org/jira/browse/EXEC-84 > Project: Commons Exec > Issue Type: New Feature > Environment: all >Reporter: Stefan Richter > > In my java application i have to execute various CommandLine applications. > Now i want to send these applications as Actors to a remote machine. The most > natural would be to have the CommandLine object of apache exec in the Actor > message. However, the CommandLine does not implement the Serializable > interface. Is there any problem tagging the CommandLine object as > Serializable? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Description: I've implemented a Simple UDP NTP server that can be used for debugging and testing. At minimum it can be used as a test harness to test the NTPClient class. Added appropriate junit test. The SimpleNTPServer class complements the existing NtpClient class. Implementation and test provided in attached patch file. was: I've implemented a Simple UDP NTP server example that can be used for debugging and testing. At minimum can be used as test harness to test the NTPClient class. Added appropriate junit test. The SimpleNTPServer class complements the existing NtpClient class. Implementation provided in attached patch file. > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > Attachments: ntpServer.patch.txt > > > I've implemented a Simple UDP NTP server that can be used for debugging and > testing. At minimum it can be used as a test harness to test the NTPClient > class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation and test provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Attachment: ntpServer.patch.txt > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > Attachments: ntpServer.patch.txt > > > I've implemented a Simple UDP NTP server example that can be used for > debugging and testing. At minimum can be used as test harness to test the > NTPClient class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (NET-527) Add SimpleNTPServer as example and for testing
[ https://issues.apache.org/jira/browse/NET-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason mathews updated NET-527: -- Attachment: (was: ntpServer.patch.txt) > Add SimpleNTPServer as example and for testing > -- > > Key: NET-527 > URL: https://issues.apache.org/jira/browse/NET-527 > Project: Commons Net > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: jason mathews > Labels: ntp > > I've implemented a Simple UDP NTP server example that can be used for > debugging and testing. At minimum can be used as test harness to test the > NTPClient class. Added appropriate junit test. > The SimpleNTPServer class complements the existing NtpClient class. > Implementation provided in attached patch file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (COMPRESS-254) ZipArchiveOutputStream try to switch to Zip64 when entries count over 64K entries
[
https://issues.apache.org/jira/browse/COMPRESS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-254.
-
Resolution: Won't Fix
any "fix" for this would create invalid archives according to APPNOTE.TXT
> ZipArchiveOutputStream try to switch to Zip64 when entries count over 64K
> entries
> -
>
> Key: COMPRESS-254
> URL: https://issues.apache.org/jira/browse/COMPRESS-254
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3, 1.4, 1.5, 1.6
> Environment: Unzip version < 6.0 (without Zip64 support)
>Reporter: Taras Ledkov
>
> Since version 1.3 we cannot create zip archive that contains over then 64K
> entries & without Zip64 extension.
> In case Zip64Mode.AsNeed is used target zip file cannot be open by unzip
> older then version 6.0.
> In case Zip64Mode.Never is used exception is thrown.
> Why so strong restriction as (ZipConstants,ZIP64_MAGIC_SHORT = 0x) was
> happened?
> To reproduce you can use dummy test below & [old unzip
> binaries|ftp://ftp.info-zip.org/pub/infozip/unix/]:
> {code:title=TestHuge}
> import org.apache.commons.compress.archivers.zip.ZipArchiveEntry;
> import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.OutputStream;
> public class TestHuge {
> public static void main(String[] args) throws IOException {
> try(OutputStream os = new FileOutputStream(new File("test.zip"));
> ZipArchiveOutputStream zos = new ZipArchiveOutputStream(os)) {
> zos.setLevel(0);
> for (int dirCount = 0; dirCount < 10; ++dirCount) {
> ZipArchiveEntry entryDir = new ZipArchiveEntry("dir" +
> dirCount + "/");
> zos.putArchiveEntry(entryDir);
> zos.closeArchiveEntry();
> for (int i = 0; i < 0x4000; ++i) {
> ZipArchiveEntry entryFile = new ZipArchiveEntry("dir" +
> dirCount + "/" + "file" + i);
> zos.putArchiveEntry(entryFile);
> zos.write(("" + dirCount + " " + i).getBytes());
> zos.closeArchiveEntry();
> }
> }
> zos.finish();
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (COMPRESS-265) PAX headers with "strange" names can not be writtem
[ https://issues.apache.org/jira/browse/COMPRESS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-265: Labels: tar (was: ) > PAX headers with "strange" names can not be writtem > --- > > Key: COMPRESS-265 > URL: https://issues.apache.org/jira/browse/COMPRESS-265 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.7 >Reporter: Stefan Bodewig > Labels: tar > Fix For: 1.8 > > > as noted by [~paburk] in COMPRESS-203 if a non-ASCII character is > "z-bit-cleaned" to \ this may lead to a file name for the PAX header that > looks like a directory name to TarArchiveEntry - which leads to a bug very > similar to COMPRESS-203. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COMPRESS-261) Unable to set SevenZOutputFile.setContentCompression() per SevenZArchiveEntry
[
https://issues.apache.org/jira/browse/COMPRESS-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-261:
Fix Version/s: 1.8
> Unable to set SevenZOutputFile.setContentCompression() per SevenZArchiveEntry
> -
>
> Key: COMPRESS-261
> URL: https://issues.apache.org/jira/browse/COMPRESS-261
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: xz-1.4.jar is used as LMZA lib
>Reporter: Peter Sauer
>Priority: Minor
> Fix For: 1.8
>
>
> I am unable to set the compression method per archive entry. In my example I
> try to switch from LZMA2 to COPY for the second entry. But 7zip says that
> both entry has COPY as compression method.
> {code}
> public static void main(String args[]) throws Exception {
> String t = "Das ist ein kleiner Test!";
> SevenZOutputFile sevenZOutput = new SevenZOutputFile(new File(
> "c:/tmp/test.7z"));
> sevenZOutput.setContentCompression(SevenZMethod.LZMA2);
> SevenZArchiveEntry entry = new SevenZArchiveEntry();
> entry.setName("test");
> sevenZOutput.putArchiveEntry(entry);
> sevenZOutput.write(t.getBytes());
> sevenZOutput.closeArchiveEntry();
>sevenZOutput.setContentCompression(SevenZMethod.COPY);
> entry = new SevenZArchiveEntry();
> entry.setName("test2");
> sevenZOutput.putArchiveEntry(entry);
> sevenZOutput.write(t.getBytes());
> sevenZOutput.closeArchiveEntry();
> sevenZOutput.finish();
> sevenZOutput.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (COMPRESS-258) SevenZFile should have getContentCompression()
[ https://issues.apache.org/jira/browse/COMPRESS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-258: Fix Version/s: 1.8 > SevenZFile should have getContentCompression() > -- > > Key: COMPRESS-258 > URL: https://issues.apache.org/jira/browse/COMPRESS-258 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.7 >Reporter: Stefan Mueller >Priority: Minor > Labels: 7z, 7zip > Fix For: 1.8 > > > While modifying 7z files (add, delete, ...) you have to rewrite the archive. > The method getContentCompression() would be great to copy the archive with > the same compression method. At the moment I can only guess the compression > or always use the same. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COMPRESS-203) Long directory names can not be stored in a tar archive because of error when writing PAX headers
[
https://issues.apache.org/jira/browse/COMPRESS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908358#comment-13908358
]
Stefan Bodewig commented on COMPRESS-203:
-
I've opened COMPRESS-265 for the new issue
> Long directory names can not be stored in a tar archive because of error when
> writing PAX headers
> -
>
> Key: COMPRESS-203
> URL: https://issues.apache.org/jira/browse/COMPRESS-203
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.4.1
> Environment: Ubuntu 12.04 Linux 64 bit, Windows 7 64-bit
>Reporter: Boris Terzic
> Fix For: 1.5
>
>
> Trying to add a directory to the TAR Archive that has a name longer than 100
> bytes generates an exception with a stack trace similar to the following:
> {noformat}
> java.io.IOException: request to write '114' bytes exceeds size in header of
> '0' bytes for entry
> './PaxHeaders.X/layers/openstreetmap__osm.disy.net/.tiles/1.0.0/openstreetmap__osm.disy.net/default/'
> at
> org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.write(TarArchiveOutputStream.java:385)
> at java.io.OutputStream.write(Unknown Source)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.writePaxHeaders(TarArchiveOutputStream.java:485)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:312)
> at net.disy.lib.io.tar.TarUtilities.addFile(TarUtilities.java:116)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:158)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at
> net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
> at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:77)
> at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:42)
> at
> net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.tarTreeStructure(TileCacheSetExporter.java:262)
> at
> net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.export(TileCacheSetExporter.java:111)
> at
> net.disy.gisterm.tilecacheset.desktop.controller.ExportController$1.run(ExportController.java:81)
> ... 2 more
> {noformat}
> Informal source code investigation points to the problem being that for
> directory entries the code assumes that the length is 0 in putArchiveEntry
> (see TarArchiveOutputStream:321 ) but when writing the data, it actually
> writes some data (the filename) and the length written (filename size) is
> larger than the length expected (0).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (COMPRESS-265) PAX headers with "strange" names can not be writtem
Stefan Bodewig created COMPRESS-265: --- Summary: PAX headers with "strange" names can not be writtem Key: COMPRESS-265 URL: https://issues.apache.org/jira/browse/COMPRESS-265 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.7 Reporter: Stefan Bodewig Fix For: 1.8 as noted by [~paburk] in COMPRESS-203 if a non-ASCII character is "z-bit-cleaned" to \ this may lead to a file name for the PAX header that looks like a directory name to TarArchiveEntry - which leads to a bug very similar to COMPRESS-203. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (COMPRESS-264) ZIP reads correctly with commons-compress 1.6, gives NUL bytes in 1.7
[
https://issues.apache.org/jira/browse/COMPRESS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-264.
-
Resolution: Fixed
Fix Version/s: 1.8
fixed with svn revision 1570582
The exact error condition:
* you are reading the very first entry of the archive
* the entry uses the STORED method
* the entry knows its size
any subsequent entry will work
> ZIP reads correctly with commons-compress 1.6, gives NUL bytes in 1.7
> -
>
> Key: COMPRESS-264
> URL: https://issues.apache.org/jira/browse/COMPRESS-264
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.7
> Environment: Ubuntu precise
>Reporter: Jonathan Nieder
>Priority: Minor
> Fix For: 1.8
>
>
> When running the code below, commons-compress 1.6 writes:
> Content of test.txt:
> data
> By comparison, commons-compress 1.7 writes
> Content of test.txt:
> ^@^@^@^@^@
> package com.example.jrn;
> import org.apache.commons.compress.archivers.zip.ZipArchiveEntry;
> import org.apache.commons.compress.archivers.zip.ZipArchiveInputStream;
> import java.io.ByteArrayInputStream;
> import java.io.IOException;
> import java.lang.System;
> /**
> * Hello world!
> *
> */
> public class App {
> public static void main(String[] args) {
> byte[] zip = {
>(byte)0x50, (byte)0x4b, (byte)0x03, (byte)0x04, (byte)0x0a, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x03, (byte)0x7b,
>(byte)0xd1, (byte)0x42, (byte)0x82, (byte)0xc5, (byte)0xc1, (byte)0xe6,
>(byte)0x05, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x05, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x08, (byte)0x00, (byte)0x1c, (byte)0x00,
>(byte)0x74, (byte)0x65, (byte)0x73, (byte)0x74, (byte)0x2e, (byte)0x74,
>(byte)0x78, (byte)0x74, (byte)0x55, (byte)0x54, (byte)0x09, (byte)0x00,
>(byte)0x03, (byte)0x56, (byte)0x62, (byte)0xbf, (byte)0x51, (byte)0x2a,
>(byte)0x63, (byte)0xbf, (byte)0x51, (byte)0x75, (byte)0x78, (byte)0x0b,
>(byte)0x00, (byte)0x01, (byte)0x04, (byte)0x01, (byte)0xff, (byte)0x01,
>(byte)0x00, (byte)0x04, (byte)0x88, (byte)0x13, (byte)0x00, (byte)0x00,
>(byte)0x64, (byte)0x61, (byte)0x74, (byte)0x61, (byte)0x0a, (byte)0x50,
>(byte)0x4b, (byte)0x01, (byte)0x02, (byte)0x1e, (byte)0x03, (byte)0x0a,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x03,
>(byte)0x7b, (byte)0xd1, (byte)0x42, (byte)0x82, (byte)0xc5, (byte)0xc1,
>(byte)0xe6, (byte)0x05, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x05,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x08, (byte)0x00, (byte)0x18,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x01,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0xa0, (byte)0x81, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x74, (byte)0x65, (byte)0x73,
>(byte)0x74, (byte)0x2e, (byte)0x74, (byte)0x78, (byte)0x74, (byte)0x55,
>(byte)0x54, (byte)0x05, (byte)0x00, (byte)0x03, (byte)0x56, (byte)0x62,
>(byte)0xbf, (byte)0x51, (byte)0x75, (byte)0x78, (byte)0x0b, (byte)0x00,
>(byte)0x01, (byte)0x04, (byte)0x01, (byte)0xff, (byte)0x01, (byte)0x00,
>(byte)0x04, (byte)0x88, (byte)0x13, (byte)0x00, (byte)0x00, (byte)0x50,
>(byte)0x4b, (byte)0x05, (byte)0x06, (byte)0x00, (byte)0x00, (byte)0x00,
>(byte)0x00, (byte)0x01, (byte)0x00, (byte)0x01, (byte)0x00, (byte)0x4e,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x47, (byte)0x00, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)00
> };
> ByteArrayInputStream bin = new ByteArrayInputStream(zip);
> try {
> ZipArchiveInputStream in = new ZipArchiveInputStream(bin);
> try {
> while (true) {
> ZipArchiveEntry entry = in.getNextZipEntry();
> if (entry == null) {
> break;
> }
> byte[] buf = new byte[(int) entry.getSize()];
> in.read(buf);
> System.out.println("Content of " + entry.getName() + ":");
> System.out.write(buf);
> }
> } finally {
> in.close();
> }
> } catch (IOException e) {
> System.err.println("IOException: " + e);
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (MATH-1101) QR and Rank-revealing QR fail to find a least-squares solution
[
https://issues.apache.org/jira/browse/MATH-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908324#comment-13908324
]
Luc Maisonobe commented on MATH-1101:
-
I am not sure to understand. The matrix is exactly singular here, which is
correctly identified if you pass a threshold of about 2e-16 to the
QRDecomposition constructor (without passing it, the default threshold is an
exact 0). With the default 0 threshold, the last diagonal element is really
small (8.88e-16) and using it implies computing big values.
As all dimensions are 3, I don't understand were you intend to have a least
squares solution. What is attempted here seems to be computing a full linear
solution of a singular problem.
> QR and Rank-revealing QR fail to find a least-squares solution
> --
>
> Key: MATH-1101
> URL: https://issues.apache.org/jira/browse/MATH-1101
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Roman Werpachowski
> Labels: solver
> Attachments: math-1101-bug.java
>
>
> QR and RRQR (rank-revealing) algorithms fail to find a least-squares solution
> in some cases.
> The following code:
> final RealMatrix A = new BlockRealMatrix(3, 3);
> A.setEntry(0, 0, 1);
> A.setEntry(0, 1, 6);
> A.setEntry(0, 2, 4);
> A.setEntry(1, 0, 2);
> A.setEntry(1, 1, 4);
> A.setEntry(1, 2, -1);
> A.setEntry(2, 0, -1);
> A.setEntry(2, 1, 2);
> A.setEntry(2, 2, 5);
> final RealVector b = new ArrayRealVector(new double[]{5, 6, 1});
> final QRDecomposition qrDecomposition = new QRDecomposition(A);
> final RRQRDecomposition rrqrDecomposition = new RRQRDecomposition(A);
> final SingularValueDecomposition svd = new
> SingularValueDecomposition(A);
> final RealVector xQR = qrDecomposition.getSolver().solve(b);
> System.out.printf("QR solution: %s\n", xQR.toString());
> final RealVector xRRQR = rrqrDecomposition.getSolver().solve(b);
> System.out.printf("RRSQ solution: %s\n", xRRQR.toString());
> final RealVector xSVD = svd.getSolver().solve(b);
> System.out.printf("SVD solution: %s\n", xSVD.toString());
> produces
> QR solution: {-3,575,212,378,628,897; 1,462,586,882,166,368;
> -1,300,077,228,592,326.5}
> RRSQ solution: {5,200,308,914,369,308; -2,127,399,101,332,898;
> 1,891,021,423,407,021}
> SVD solution: {0.5050344462; 1.0206677266; -0.2405935347}
> Showing that QR and RRQR algorithms fail to find the least-squares solution.
> This can also be verified by calculating the dot product between columns of A
> and A*x - b:
> // x = xQR, xRRQR or xSVD
> final RealVector r = A.operate(x).subtract(b);
> for (int i = 0; i < x.getDimension(); ++i) {
> final RealVector columnVector = A.getColumnVector(i);
> assertEquals(name, 0.0, r.dotProduct(columnVector), tolerance);
> }
> Only SVD method passes this test with decent tolerance (1E-14 or so).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COMPRESS-264) ZIP reads correctly with commons-compress 1.6, gives NUL bytes in 1.7
[
https://issues.apache.org/jira/browse/COMPRESS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908297#comment-13908297
]
Stefan Bodewig commented on COMPRESS-264:
-
I've turned your example into a unit test with svn revision 1570567
As a workaround it might help you to know that ZipFile works as expected in 1.7.
> ZIP reads correctly with commons-compress 1.6, gives NUL bytes in 1.7
> -
>
> Key: COMPRESS-264
> URL: https://issues.apache.org/jira/browse/COMPRESS-264
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.7
> Environment: Ubuntu precise
>Reporter: Jonathan Nieder
>Priority: Minor
>
> When running the code below, commons-compress 1.6 writes:
> Content of test.txt:
> data
> By comparison, commons-compress 1.7 writes
> Content of test.txt:
> ^@^@^@^@^@
> package com.example.jrn;
> import org.apache.commons.compress.archivers.zip.ZipArchiveEntry;
> import org.apache.commons.compress.archivers.zip.ZipArchiveInputStream;
> import java.io.ByteArrayInputStream;
> import java.io.IOException;
> import java.lang.System;
> /**
> * Hello world!
> *
> */
> public class App {
> public static void main(String[] args) {
> byte[] zip = {
>(byte)0x50, (byte)0x4b, (byte)0x03, (byte)0x04, (byte)0x0a, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x03, (byte)0x7b,
>(byte)0xd1, (byte)0x42, (byte)0x82, (byte)0xc5, (byte)0xc1, (byte)0xe6,
>(byte)0x05, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x05, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x08, (byte)0x00, (byte)0x1c, (byte)0x00,
>(byte)0x74, (byte)0x65, (byte)0x73, (byte)0x74, (byte)0x2e, (byte)0x74,
>(byte)0x78, (byte)0x74, (byte)0x55, (byte)0x54, (byte)0x09, (byte)0x00,
>(byte)0x03, (byte)0x56, (byte)0x62, (byte)0xbf, (byte)0x51, (byte)0x2a,
>(byte)0x63, (byte)0xbf, (byte)0x51, (byte)0x75, (byte)0x78, (byte)0x0b,
>(byte)0x00, (byte)0x01, (byte)0x04, (byte)0x01, (byte)0xff, (byte)0x01,
>(byte)0x00, (byte)0x04, (byte)0x88, (byte)0x13, (byte)0x00, (byte)0x00,
>(byte)0x64, (byte)0x61, (byte)0x74, (byte)0x61, (byte)0x0a, (byte)0x50,
>(byte)0x4b, (byte)0x01, (byte)0x02, (byte)0x1e, (byte)0x03, (byte)0x0a,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x03,
>(byte)0x7b, (byte)0xd1, (byte)0x42, (byte)0x82, (byte)0xc5, (byte)0xc1,
>(byte)0xe6, (byte)0x05, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x05,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x08, (byte)0x00, (byte)0x18,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x01,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0xa0, (byte)0x81, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x74, (byte)0x65, (byte)0x73,
>(byte)0x74, (byte)0x2e, (byte)0x74, (byte)0x78, (byte)0x74, (byte)0x55,
>(byte)0x54, (byte)0x05, (byte)0x00, (byte)0x03, (byte)0x56, (byte)0x62,
>(byte)0xbf, (byte)0x51, (byte)0x75, (byte)0x78, (byte)0x0b, (byte)0x00,
>(byte)0x01, (byte)0x04, (byte)0x01, (byte)0xff, (byte)0x01, (byte)0x00,
>(byte)0x04, (byte)0x88, (byte)0x13, (byte)0x00, (byte)0x00, (byte)0x50,
>(byte)0x4b, (byte)0x05, (byte)0x06, (byte)0x00, (byte)0x00, (byte)0x00,
>(byte)0x00, (byte)0x01, (byte)0x00, (byte)0x01, (byte)0x00, (byte)0x4e,
>(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x47, (byte)0x00, (byte)0x00,
>(byte)0x00, (byte)0x00, (byte)00
> };
> ByteArrayInputStream bin = new ByteArrayInputStream(zip);
> try {
> ZipArchiveInputStream in = new ZipArchiveInputStream(bin);
> try {
> while (true) {
> ZipArchiveEntry entry = in.getNextZipEntry();
> if (entry == null) {
> break;
> }
> byte[] buf = new byte[(int) entry.getSize()];
> in.read(buf);
> System.out.println("Content of " + entry.getName() + ":");
> System.out.write(buf);
> }
> } finally {
> in.close();
> }
> } catch (IOException e) {
> System.err.println("IOException: " + e);
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (MATH-1053) QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices
[ https://issues.apache.org/jira/browse/MATH-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1053. - Resolution: Fixed Fix Version/s: 3.3 Fixed in subversion repository as of r1570566. Thanks for the report and for the patch. > QRDecomposition.getSolver() should be able to find pseudo-inverse of > non-square matrices > > > Key: MATH-1053 > URL: https://issues.apache.org/jira/browse/MATH-1053 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Sean Owen >Priority: Minor > Fix For: 3.3 > > Attachments: MATH-1053.patch > > > I don't have a complete solution to this, so don't commit this as-is, but > posting in case someone can get it over the line. > If you process a tall m x n matrix (non-square, m>n) with QRDecomposition and > then call getSolver().getInverse(), you will get DimensionMismatchException. > There's not a good reason the QR decomposition can't compute the > least-squares solution here. > The issue is that it tries to invert A by solving AX = I. The dimension of I > has to match the row dimension of A, or m. However it's using the length of > the diagonal of R, which is min(m,n), which is n when m>n. > That patch is simple and is part of the attached patch. It also includes a > test case for a tall matrix. > However it doesn't work for a fat matrix (m too. It returns an n x m value but the rows for i >= m are 0 and are not > computed. I'm not sure enough about the shape of the computation to be able > to fix it, but it is where it's solving the triangular system Rx = y. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (MATH-1101) QR and Rank-revealing QR fail to find a least-squares solution
[
https://issues.apache.org/jira/browse/MATH-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Werpachowski updated MATH-1101:
-
Attachment: math-1101-bug.java
Attached test code for convenience.
> QR and Rank-revealing QR fail to find a least-squares solution
> --
>
> Key: MATH-1101
> URL: https://issues.apache.org/jira/browse/MATH-1101
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Roman Werpachowski
> Labels: solver
> Attachments: math-1101-bug.java
>
>
> QR and RRQR (rank-revealing) algorithms fail to find a least-squares solution
> in some cases.
> The following code:
> final RealMatrix A = new BlockRealMatrix(3, 3);
> A.setEntry(0, 0, 1);
> A.setEntry(0, 1, 6);
> A.setEntry(0, 2, 4);
> A.setEntry(1, 0, 2);
> A.setEntry(1, 1, 4);
> A.setEntry(1, 2, -1);
> A.setEntry(2, 0, -1);
> A.setEntry(2, 1, 2);
> A.setEntry(2, 2, 5);
> final RealVector b = new ArrayRealVector(new double[]{5, 6, 1});
> final QRDecomposition qrDecomposition = new QRDecomposition(A);
> final RRQRDecomposition rrqrDecomposition = new RRQRDecomposition(A);
> final SingularValueDecomposition svd = new
> SingularValueDecomposition(A);
> final RealVector xQR = qrDecomposition.getSolver().solve(b);
> System.out.printf("QR solution: %s\n", xQR.toString());
> final RealVector xRRQR = rrqrDecomposition.getSolver().solve(b);
> System.out.printf("RRSQ solution: %s\n", xRRQR.toString());
> final RealVector xSVD = svd.getSolver().solve(b);
> System.out.printf("SVD solution: %s\n", xSVD.toString());
> produces
> QR solution: {-3,575,212,378,628,897; 1,462,586,882,166,368;
> -1,300,077,228,592,326.5}
> RRSQ solution: {5,200,308,914,369,308; -2,127,399,101,332,898;
> 1,891,021,423,407,021}
> SVD solution: {0.5050344462; 1.0206677266; -0.2405935347}
> Showing that QR and RRQR algorithms fail to find the least-squares solution.
> This can also be verified by calculating the dot product between columns of A
> and A*x - b:
> // x = xQR, xRRQR or xSVD
> final RealVector r = A.operate(x).subtract(b);
> for (int i = 0; i < x.getDimension(); ++i) {
> final RealVector columnVector = A.getColumnVector(i);
> assertEquals(name, 0.0, r.dotProduct(columnVector), tolerance);
> }
> Only SVD method passes this test with decent tolerance (1E-14 or so).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (MATH-1101) QR and Rank-revealing QR fail to find a least-squares solution
Roman Werpachowski created MATH-1101:
Summary: QR and Rank-revealing QR fail to find a least-squares
solution
Key: MATH-1101
URL: https://issues.apache.org/jira/browse/MATH-1101
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.2
Reporter: Roman Werpachowski
QR and RRQR (rank-revealing) algorithms fail to find a least-squares solution
in some cases.
The following code:
final RealMatrix A = new BlockRealMatrix(3, 3);
A.setEntry(0, 0, 1);
A.setEntry(0, 1, 6);
A.setEntry(0, 2, 4);
A.setEntry(1, 0, 2);
A.setEntry(1, 1, 4);
A.setEntry(1, 2, -1);
A.setEntry(2, 0, -1);
A.setEntry(2, 1, 2);
A.setEntry(2, 2, 5);
final RealVector b = new ArrayRealVector(new double[]{5, 6, 1});
final QRDecomposition qrDecomposition = new QRDecomposition(A);
final RRQRDecomposition rrqrDecomposition = new RRQRDecomposition(A);
final SingularValueDecomposition svd = new
SingularValueDecomposition(A);
final RealVector xQR = qrDecomposition.getSolver().solve(b);
System.out.printf("QR solution: %s\n", xQR.toString());
final RealVector xRRQR = rrqrDecomposition.getSolver().solve(b);
System.out.printf("RRSQ solution: %s\n", xRRQR.toString());
final RealVector xSVD = svd.getSolver().solve(b);
System.out.printf("SVD solution: %s\n", xSVD.toString());
produces
QR solution: {-3,575,212,378,628,897; 1,462,586,882,166,368;
-1,300,077,228,592,326.5}
RRSQ solution: {5,200,308,914,369,308; -2,127,399,101,332,898;
1,891,021,423,407,021}
SVD solution: {0.5050344462; 1.0206677266; -0.2405935347}
Showing that QR and RRQR algorithms fail to find the least-squares solution.
This can also be verified by calculating the dot product between columns of A
and A*x - b:
// x = xQR, xRRQR or xSVD
final RealVector r = A.operate(x).subtract(b);
for (int i = 0; i < x.getDimension(); ++i) {
final RealVector columnVector = A.getColumnVector(i);
assertEquals(name, 0.0, r.dotProduct(columnVector), tolerance);
}
Only SVD method passes this test with decent tolerance (1E-14 or so).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (MATH-1009) PolynomialFitter
[ https://issues.apache.org/jira/browse/MATH-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1009. - Resolution: Fixed Fix Version/s: 3.3 Issue fixed along with MATH-1099 > PolynomialFitter > > > Key: MATH-1009 > URL: https://issues.apache.org/jira/browse/MATH-1009 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 > Environment: All >Reporter: Konstantin Berlin >Priority: Minor > Fix For: 3.3 > > > org.apache.commons.math3.fitting.PolynomialFitter > should be implemented using linear least-squares method like QR decomposition > solver. > There are several reasons for this > 1) Nonlinear methods are much slower > 2) Linear methods (QR and SVD) are numerically more stable. > 3) By storing the QR decomposition it is possible to recompute the solution > for different input data values. > See > http://mathworld.wolfram.com/LeastSquaresFittingPolynomial.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (MATH-820) Implement the visitor pattern for FieldVector
[
https://issues.apache.org/jira/browse/MATH-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-820.
Resolution: Fixed
Fix Version/s: 3.3
Fixed in subversion repository as of r1570536.
> Implement the visitor pattern for FieldVector
> -
>
> Key: MATH-820
> URL: https://issues.apache.org/jira/browse/MATH-820
> Project: Commons Math
> Issue Type: Wish
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>Priority: Minor
> Fix For: 3.3
>
>
> This is a continuation of MATH-792: the same feature should be implemented
> for {{FieldVector}}, in order to maintain the consistency of the APIs.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (COMMONSSITE-78) Alignment Issues on Commons Welcome Page
[ https://issues.apache.org/jira/browse/COMMONSSITE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter resolved COMMONSSITE-78. Resolution: Not A Problem > Alignment Issues on Commons Welcome Page > > > Key: COMMONSSITE-78 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-78 > Project: Commons All > Issue Type: Bug > Components: Commons Skin > Environment: Chrome Version 32.0.1700.107 > Windows 7 >Reporter: Andre Diermann > Attachments: Issue#1.PNG, Issue#2.PNG, Issue#3.PNG > > > When browsing http://commons.apache.org/ with the new skin, I am encountering > several issues regarding the alignment of some page items: > #1: The publish and version information in the navigation bar seems to align > to top instead of beeing centered vertically like the other items within the > navigation bar. > #2: The left-hand side menu is centered vertically which makes it somehow > invisible. The user has to scroll down on larger pages such as the above > mentioned start page. > #3: The footer seems to be not formatted correctly when compared to the > footer of http://commons.apache.org/proper/commons-weaver/ > See attached screenshots. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (COMMONSSITE-78) Alignment Issues on Commons Welcome Page
[ https://issues.apache.org/jira/browse/COMMONSSITE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter reopened COMMONSSITE-78: Reopening to resolve as not a problem > Alignment Issues on Commons Welcome Page > > > Key: COMMONSSITE-78 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-78 > Project: Commons All > Issue Type: Bug > Components: Commons Skin > Environment: Chrome Version 32.0.1700.107 > Windows 7 >Reporter: Andre Diermann > Attachments: Issue#1.PNG, Issue#2.PNG, Issue#3.PNG > > > When browsing http://commons.apache.org/ with the new skin, I am encountering > several issues regarding the alignment of some page items: > #1: The publish and version information in the navigation bar seems to align > to top instead of beeing centered vertically like the other items within the > navigation bar. > #2: The left-hand side menu is centered vertically which makes it somehow > invisible. The user has to scroll down on larger pages such as the above > mentioned start page. > #3: The footer seems to be not formatted correctly when compared to the > footer of http://commons.apache.org/proper/commons-weaver/ > See attached screenshots. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (MATH-875) Deprecate RealVector.sparseIterator()
[
https://issues.apache.org/jira/browse/MATH-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-875.
Resolution: Fixed
Fix Version/s: 3.3
Un-deprecated method in r1570510.
The documentation explicitly states that ignored entires are the exact zero
ones.
This is part of Apache Commons Math reconsidering support for sparse
linear algebra.
> Deprecate RealVector.sparseIterator()
> -
>
> Key: MATH-875
> URL: https://issues.apache.org/jira/browse/MATH-875
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Sébastien Brisard
>Priority: Minor
> Labels: linear, sparse
> Fix For: 3.3
>
>
> Following MATH-870, {{RealVector.sparseIterator()}} has become useless. Its
> interface was confusing. Indeed, the Javadoc states
> {quote}
> Specialized implementations may choose to not iterate over all dimensions,
> either because those values are unset, or are equal to defaultValue(), or are
> small enough to be ignored for the purposes of iteration.
> {quote}
> The reference to {{defaultValue()}} (which does *not* exist) suggests that
> the interface offers the flexibility to chose the value which is not stored
> in the sparse implementation. On the other hand, "small enough to be ignored"
> suggests that this default value is zero.
> In version 3.1, this method will be deprecated, to be removed in 4.0.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (MATH-1100) QR factorization fails in revealing rank-deficient matrix
[ https://issues.apache.org/jira/browse/MATH-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1100. - Resolution: Invalid Fix Version/s: 3.3 As per comments above, specifying the threshold allows to correctly identify the rank. > QR factorization fails in revealing rank-deficient matrix > - > > Key: MATH-1100 > URL: https://issues.apache.org/jira/browse/MATH-1100 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, > sharing) an windows 7 professional >Reporter: alberto trivellato > Fix For: 3.3 > > Attachments: QRtest.zip > > > given a matrix that has not full rank, the method getSolver().isNonSingular() > of the class QRDecomposition returns true. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (EXEC-84) CommandLine implementing Serializeable
Stefan Richter created EXEC-84: -- Summary: CommandLine implementing Serializeable Key: EXEC-84 URL: https://issues.apache.org/jira/browse/EXEC-84 Project: Commons Exec Issue Type: New Feature Environment: all Reporter: Stefan Richter In my java application i have to execute various CommandLine applications. Now i want to send these applications as Actors to a remote machine. The most natural would be to have the CommandLine object of apache exec in the Actor message. However, the CommandLine does not implement the Serializable interface. Is there any problem tagging the CommandLine object as Serializable? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (COMMONSSITE-78) Alignment Issues on Commons Welcome Page
[ https://issues.apache.org/jira/browse/COMMONSSITE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908094#comment-13908094 ] Andre Diermann commented on COMMONSSITE-78: --- Yeah, I changed the issue to resolved. Unfortunately I am not aware of the version which fixes the issue. If this information is important please tell me so that I can update it. (Or maybe update by yourself if this is possible somehow :)) > Alignment Issues on Commons Welcome Page > > > Key: COMMONSSITE-78 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-78 > Project: Commons All > Issue Type: Bug > Components: Commons Skin > Environment: Chrome Version 32.0.1700.107 > Windows 7 >Reporter: Andre Diermann > Attachments: Issue#1.PNG, Issue#2.PNG, Issue#3.PNG > > > When browsing http://commons.apache.org/ with the new skin, I am encountering > several issues regarding the alignment of some page items: > #1: The publish and version information in the navigation bar seems to align > to top instead of beeing centered vertically like the other items within the > navigation bar. > #2: The left-hand side menu is centered vertically which makes it somehow > invisible. The user has to scroll down on larger pages such as the above > mentioned start page. > #3: The footer seems to be not formatted correctly when compared to the > footer of http://commons.apache.org/proper/commons-weaver/ > See attached screenshots. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (COMMONSSITE-78) Alignment Issues on Commons Welcome Page
[ https://issues.apache.org/jira/browse/COMMONSSITE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andre Diermann resolved COMMONSSITE-78. --- Resolution: Fixed > Alignment Issues on Commons Welcome Page > > > Key: COMMONSSITE-78 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-78 > Project: Commons All > Issue Type: Bug > Components: Commons Skin > Environment: Chrome Version 32.0.1700.107 > Windows 7 >Reporter: Andre Diermann > Attachments: Issue#1.PNG, Issue#2.PNG, Issue#3.PNG > > > When browsing http://commons.apache.org/ with the new skin, I am encountering > several issues regarding the alignment of some page items: > #1: The publish and version information in the navigation bar seems to align > to top instead of beeing centered vertically like the other items within the > navigation bar. > #2: The left-hand side menu is centered vertically which makes it somehow > invisible. The user has to scroll down on larger pages such as the above > mentioned start page. > #3: The footer seems to be not formatted correctly when compared to the > footer of http://commons.apache.org/proper/commons-weaver/ > See attached screenshots. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
