[jira] [Updated] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Livia Sarbu updated COMPRESS-252: - Summary: Writing 7z empty entries produces incorrect or corrupt archive (was: Writing 7z empty entries with LZMA2 produces incorrect or corrupt archive) Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COMPRESS-252) Writing 7z empty entries with LZMA2 produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853795#comment-13853795 ] Livia Sarbu commented on COMPRESS-252: -- I didn't test with other compression methods, than. Did that now, and it's the same, so I will delete that part from the description. Writing 7z empty entries with LZMA2 produces incorrect or corrupt archive - Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853799#comment-13853799 ] Stefan Bodewig commented on COMPRESS-252: - I was afraid you'd say so. Thanks for checking. Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (POOL-245) [PATCH] Typo and remove duplicate null check
[ https://issues.apache.org/jira/browse/POOL-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-245. -- Resolution: Fixed Fix Version/s: 2.1 Thanks for the patch. I applied it but with a few changes: - there were lots of cases of it's rather than its so I fixed them all. - I removed rather than commented out the duplicate check to reduce the clutter in the code base. Thanks again for the patch - on to your next one ;) [PATCH] Typo and remove duplicate null check Key: POOL-245 URL: https://issues.apache.org/jira/browse/POOL-245 Project: Commons Pool Issue Type: Improvement Reporter: Bruno P. Kinoshita Priority: Trivial Labels: patch, typo Fix For: 2.1 Attachments: POOL-245.patch This patch fixes a trivial typo in PoolUtils javadocs, and removes a duplicate null check. There is no way (besides reflection, mocking, etc) to test both null checks. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (POOL-246) [PATCH] Follow same pattern in ErodingKeyedObjectPool#toString as in other pool objects
[
https://issues.apache.org/jira/browse/POOL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-246.
--
Resolution: Fixed
Fix Version/s: 2.1
Patch applied. Many thanks.
[PATCH] Follow same pattern in ErodingKeyedObjectPool#toString as in other
pool objects
---
Key: POOL-246
URL: https://issues.apache.org/jira/browse/POOL-246
Project: Commons Pool
Issue Type: Improvement
Reporter: Bruno P. Kinoshita
Priority: Trivial
Labels: patch
Fix For: 2.1
Attachments: POOL-246.patch
Hello!
In ErodingObjectPool, the toString method outputs:
ErodingObjectPool{factor=$FACTOR, pool=$POOL}
And in ErodingPerKeyKeyedObjectPool it outputs:
ErodingPerKeyKeyedObjectPool{factor=, keyedPool=$POOL}
However, in ErodingKeyedObjectPool, the factor has a different prefix:
ErodingKeyedObjectPool{erodingFactor=$FACTOR, keyedPool=$POOL}
This proposed patch follows the same pattern as in the aforementioned pools
and changes ErodingKeyedObjectPool#toString.
Please, note that POOL-244 contains tests that may fail due to this change,
so during the merge it may be good to take a look at
TestPoolUtils#testErodingPoolKeyedObjectPoolDefaultFactor to avoid build
errors.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (POOL-244) [PATCH] Add more tests to [pool]
[ https://issues.apache.org/jira/browse/POOL-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-244. -- Resolution: Fixed Fix Version/s: 2.1 Thanks again. Patch applied. [PATCH] Add more tests to [pool] Key: POOL-244 URL: https://issues.apache.org/jira/browse/POOL-244 Project: Commons Pool Issue Type: Test Reporter: Bruno P. Kinoshita Priority: Trivial Labels: coverage, patch, tests Fix For: 2.1 Attachments: POOL-244.patch Hi! I read a new version of [pool] was being prepared to be released and decided to chime in and add a few more tests. With these new tests, I believe the line coverage is above 70% is almost all the inner/classes but one that I thought wasn't worth writing more tests. In future dev cycles I hope to be able to increase the branch coverage to somewhere near 70% too, as well as fix some of the TODO tasks in the test code. I found a few trivial things that could be changed I think (typos, unreachable if's and naming inconsistencies) but I'll create separate issues for each one. Please, feel free to massage the code as much as needed or drop any parts if needed. Hope that helps, Bruno -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853869#comment-13853869 ] Stefan Bodewig commented on COMPRESS-252: - I think I found the problem, need to add a bunch of more tests and commit then. 7 or more really is a magic number as the method writing bitsets has an off-by-one bug. Will comment here, when I've committed the fix. Do you think you can build Compress from trunk and verify it works for you after that? Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853897#comment-13853897 ] Stefan Bodewig commented on COMPRESS-252: - svn revision 1552608 Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-252: Fix Version/s: 1.7 Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Fix For: 1.7 Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-252: Labels: 7z (was: ) Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Labels: 7z Fix For: 1.7 Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (COMPRESS-244) 7z reading of UINT64 data type is wrong for big values
[
https://issues.apache.org/jira/browse/COMPRESS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-244:
Labels: 7z easyfix patch (was: easyfix patch)
7z reading of UINT64 data type is wrong for big values
--
Key: COMPRESS-244
URL: https://issues.apache.org/jira/browse/COMPRESS-244
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.6
Reporter: Nico Kruber
Labels: 7z, easyfix, patch
Fix For: 1.7
Attachments: fix-readUint64-for-large-values.diff
h2. Brief description
large values with a first byte indicating at least 4 additional bytes shift
an integer by at least 32bits thus leading to an overflow and an incorrect
value - the value needs to be casted to long before the bitshift!
(see the attached patch)
h2. Details from the 7z documentation
{quote}
{noformat}
UINT64 means real UINT64 encoded with the following scheme:
Size of encoding sequence depends from first byte:
First_Byte Extra_BytesValue
(binary)
0xxx : ( xxx )
10xxBYTE y[1] : ( xx (8 * 1)) + y
110xBYTE y[2] : ( x (8 * 2)) + y
...
110xBYTE y[6] : ( x (8 * 6)) + y
1110BYTE y[7] : y
BYTE y[8] : y
{noformat}
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (COMPRESS-245) TarArchiveInputStream#getNextTarEntry returns null prematurely
[
https://issues.apache.org/jira/browse/COMPRESS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-245:
Labels: tar (was: )
TarArchiveInputStream#getNextTarEntry returns null prematurely
--
Key: COMPRESS-245
URL: https://issues.apache.org/jira/browse/COMPRESS-245
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.6
Environment: Linux
Reporter: Andreas Aronsson
Labels: tar
Fix For: 1.7
Attachments: exampletar.tar.gz
The attached archive decompressed with 1.6 only extracts part of the archive.
This does not happen with version 1.5
{code:java}
FileInputStream fin = new FileInputStream(exampletar.tar.gz);
GZIPInputStream gin = new GZIPInputStream(fin);
TarArchiveInputStream tin = new TarArchiveInputStream(gin);
TarArchiveEntry entry;
while ((entry = tin.getNextTarEntry()) != null) {
{code}
The file is created with {code}tar cvzf{code} in RHEL 6.5 and the contents
look like this when extracted with the same tool:
{noformat}
topdirectory/
topdirectory/about.html
topdirectory/.eclipseproduct
topdirectory/plugins/
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/about.html
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/eclipse.inf
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/ECLIPSEF.SF
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/MANIFEST.MF
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/ECLIPSEF.RSA
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/launcher.gtk.linux.x86_64.properties
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/eclipse_1206.so
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/about.html
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/fragment.properties
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/.api_description
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/META-INF/
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/META-INF/eclipse.inf
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/META-INF/ECLIPSEF.SF
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/META-INF/MANIFEST.MF
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/META-INF/ECLIPSEF.RSA
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800/runtime_registry_compatibility.jar
topdirectory/configuration/
topdirectory/configuration/config.ini
topdirectory/icon.xpm
topdirectory/about_files/
topdirectory/about_files/pixman-licenses.txt
topdirectory/about_files/mpl-v11.txt
topdirectory/about_files/about_cairo.html
topdirectory/libcairo-swt.so
{noformat}
with commons-compress-1.6 it looks like this:
{noformat}
topdirectory/
topdirectory/about.html
topdirectory/.eclipseproduct
topdirectory/plugins
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/about.html
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/eclipse.inf
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/ECLIPSEF.SF
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/MANIFEST.MF
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/META-INF/ECLIPSEF.RSA
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/launcher.gtk.linux.x86_64.properties
topdirectory/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519/eclipse_1206.so
topdirectory/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.200.v20090429-1800
[jira] [Updated] (COMPRESS-243) Provide CompressorInputStream for classic Unix compress (maybe based on LZW codec from imaging)
[ https://issues.apache.org/jira/browse/COMPRESS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-243: Labels: zip (was: ) Provide CompressorInputStream for classic Unix compress (maybe based on LZW codec from imaging) --- Key: COMPRESS-243 URL: https://issues.apache.org/jira/browse/COMPRESS-243 Project: Commons Compress Issue Type: New Feature Components: Archivers Reporter: Stefan Bodewig Priority: Minor Labels: zip Fix For: 1.7 https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (COMPRESS-243) Provide CompressorInputStream for classic Unix compress (maybe based on LZW codec from imaging)
[ https://issues.apache.org/jira/browse/COMPRESS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-243: Component/s: Archivers Provide CompressorInputStream for classic Unix compress (maybe based on LZW codec from imaging) --- Key: COMPRESS-243 URL: https://issues.apache.org/jira/browse/COMPRESS-243 Project: Commons Compress Issue Type: New Feature Components: Archivers Reporter: Stefan Bodewig Priority: Minor Labels: zip Fix For: 1.7 https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (COMPRESS-147) Add a Snappy decompressor
[ https://issues.apache.org/jira/browse/COMPRESS-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-147: Labels: snappy (was: ) Add a Snappy decompressor - Key: COMPRESS-147 URL: https://issues.apache.org/jira/browse/COMPRESS-147 Project: Commons Compress Issue Type: Wish Components: Compressors Reporter: Christian Grobmeier Priority: Minor Labels: snappy Fix For: 1.7 Attachments: SnappyDecompressor.java Add a Snappy compressor to the Compress lib. Currently there is only a C implementation linked with JNI to Java. [1] http://code.google.com/p/snappy/ [2] http://code.google.com/p/snappy-java/ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (COMPRESS-250) Setting the compression level for GzipCompressorOutputStream
[ https://issues.apache.org/jira/browse/COMPRESS-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-250: Labels: gzip (was: ) Setting the compression level for GzipCompressorOutputStream Key: COMPRESS-250 URL: https://issues.apache.org/jira/browse/COMPRESS-250 Project: Commons Compress Issue Type: Improvement Components: Compressors Reporter: Emmanuel Bourg Priority: Minor Labels: gzip Fix For: 1.7 There is no way to set the compression level of GzipCompressorOutputStream. It uses the default level of GZIPOutputStream which isn't the best available. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (COMPRESS-242) X5455_ExtendedTimestamp's API is inconvenient for writers
[ https://issues.apache.org/jira/browse/COMPRESS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-242: Labels: zip (was: ) X5455_ExtendedTimestamp's API is inconvenient for writers - Key: COMPRESS-242 URL: https://issues.apache.org/jira/browse/COMPRESS-242 Project: Commons Compress Issue Type: Improvement Components: Archivers Affects Versions: 1.5, 1.6 Reporter: Stefan Bodewig Priority: Minor Labels: zip Fix For: 1.7 The extra field doesn't do anything useful unless you call setFlags explicitly. This is non-obviuos and not really documented well. The fact that the *_TIME_BIT constants are package private doesn't help either. IMHO the constants should be public, the time field setters should set their corresponding flags implicitly when invoked with non-null values (rest when invoked with null values, perhaps) and the documentation clarified. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853924#comment-13853924 ] Livia Sarbu commented on COMPRESS-252: -- I will take it from trunk and check it, but I am not sure I will have time today; I will let you know when I do. Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Labels: 7z Fix For: 1.7 Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13853951#comment-13853951 ] Stefan Bodewig commented on COMPRESS-252: - Thanks. Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Labels: 7z Fix For: 1.7 Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (LANG-936) StringUtils.getLevenshteinDistance with too big of a threshold returns wrong result
[
https://issues.apache.org/jira/browse/LANG-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-936:
-
Fix Version/s: Patch Needed
StringUtils.getLevenshteinDistance with too big of a threshold returns wrong
result
---
Key: LANG-936
URL: https://issues.apache.org/jira/browse/LANG-936
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Reporter: Yaniv Kunda
Priority: Minor
Fix For: Patch Needed
StringUtils.getLevenshteinDistance(CharSequence s, CharSequence t, int
threshold) specifies:
{quote}
{{Find the Levenshtein distance between two Strings if it's _+*less than or
equal to*+_ a given threshold.}}
{quote}
When passing a threshold *Integer.MAX_VALUE - max(s.length(), t.length())*
the method always returns -1.
The simplest use case is passing *Integer.MAX_VALUE* (a common practice if
one would want to find the min/max LD of a string to several other strings in
an iterative fashion.
The code should be fixed to consider the threshold in relation to the
source/target lengths, or alternatively the javadoc should be fixed to
pronounce the current limit.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854000#comment-13854000 ] Benedikt Ritter commented on LANG-769: -- What about UnhandledException? Do we want to add it or can we close this ticket for 3.2? Please restore NotImplementedException and UnhandledException - Key: LANG-769 URL: https://issues.apache.org/jira/browse/LANG-769 Project: Commons Lang Issue Type: Improvement Components: lang.exception.* Reporter: david cogen Priority: Minor Fix For: 3.2 Why were these removed? I found these very useful and used them often. As the version 2.6 api javadoc states, This exception supplements the standard exception classes by providing a more semantically rich description of the problem. Just want you to realize that these have found direct use outside the library; not just internal use within commons-lang. I will define these missing classes myself, or maybe include both commons-lang and commons-lang3 (but I really don't to do that). It would be very nice to have these back. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (IO-419) InputStream That Removes Invalid XML Characters
[ https://issues.apache.org/jira/browse/IO-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854081#comment-13854081 ] Sebb commented on IO-419: - What is the use-case for this? InputStream That Removes Invalid XML Characters --- Key: IO-419 URL: https://issues.apache.org/jira/browse/IO-419 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: BELUGA BEHR Priority: Minor Create a FilterInputStream that removes invalid characters from an XML stream. Perhaps the InputStream keeps a count of how many bytes it removes. Invalid XML characters... http://www.w3.org/TR/xml/#charsets -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (LANG-923) JDK 1.8 Changes
[ https://issues.apache.org/jira/browse/LANG-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-923: -- Issue Type: Task (was: Bug) JDK 1.8 Changes --- Key: LANG-923 URL: https://issues.apache.org/jira/browse/LANG-923 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Fix For: 4.0 Omnibus issue to cover any JDK 1.8 related changes. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-910: -- Issue Type: Improvement (was: Bug) Patch to extend StringUtils --- Key: LANG-910 URL: https://issues.apache.org/jira/browse/LANG-910 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.1 Environment: Developed on Ubuntu 13.04 with openjdk 7u25 Reporter: Timur Yarosh Labels: patch Fix For: Discussion Attachments: LANG-910.patch, substring-matches-and-white-space-normalize.patch This patch extends StringUtils capabilities: added methods to find substring(s) by Pattern. Also method org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 char to normal whitespace. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COMPRESS-252) Writing 7z empty entries produces incorrect or corrupt archive
[ https://issues.apache.org/jira/browse/COMPRESS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854119#comment-13854119 ] Sebb commented on COMPRESS-252: --- Note: the Continuum CI server is not working currently, but I have deployed 1.7-SNAPSHOT to the ASF SNAPSHOT repo at http://repository.apache.org/snapshots in case that is of any use. Writing 7z empty entries produces incorrect or corrupt archive -- Key: COMPRESS-252 URL: https://issues.apache.org/jira/browse/COMPRESS-252 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.6 Environment: eclipse 3.7.2, java 1.7 Reporter: Livia Sarbu Priority: Blocker Labels: 7z Fix For: 1.7 Attachments: CreateArchiveTest.java, EmptyTest.zip, Scenario2and4.1.jpg, Scenario3.jpg, Scenario4.2.jpg I couldn't find an exact rule that causes this incorrect behavior, but I tried to reduce it to some simple scenarios to reproduce it: Input: A folder with certain files - tried to archive it. If the folder contains more than 7 files the incorrect behavior appears. Scenario 1: 7 empty files Result: The created archive contains a single folder entry with the name of the archive (no matter which was the name of the file) Scenario 2: 7 files, some empty, some with content Result: The created archive contains a folder entry with the name of the archive and a number of file entries also with the name of the archive. The number of the entries is equal to the number of non empty files. Scenario 3: 8 empty files Result: 7zip Manager cannot open archive and stops working. Scenario 4.1: 8 files: some empty, some with content, last file (alphabetically) with content Result: same behavior as described for Scenario 2. Scenario 4.2: 8 files, some empty, some with content, last file empy Result: archive is corrupt, the following message is received: Cannot open file 'archivename.7z' as archive (7Zip Manager does not crash). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COLLECTIONS-479) An Order Statistic Tree
[ https://issues.apache.org/jira/browse/COLLECTIONS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854155#comment-13854155 ] Rodion Efremov commented on COLLECTIONS-479: Hello, y'all! Might the ordered statistic tree look anything like [this|https://github.com/coderodde/cskit/blob/master/src/main/java/net/coderodde/cskit/ds/tree/OrderStatisticTree.java]? Rodde An Order Statistic Tree --- Key: COLLECTIONS-479 URL: https://issues.apache.org/jira/browse/COLLECTIONS-479 Project: Commons Collections Issue Type: New Feature Reporter: Ajo Fod Priority: Minor Attachments: NodeExistsException.java, RedBlackBST.java An order statistic tree http://en.wikipedia.org/wiki/Order_statistic_tree provides two useful properties. The ability to rank arbitrary keys relative to keys existing in the tree AND the ability to retrieve elements from the tree with the given rank. This can be used to find the percentile rank of a key for example. This functionality is not yet provided yet by any of the major libraries AFAIK. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COLLECTIONS-479) An Order Statistic Tree
[ https://issues.apache.org/jira/browse/COLLECTIONS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854200#comment-13854200 ] Ajo Fod commented on COLLECTIONS-479: - Yes, that looks right. -Ajo An Order Statistic Tree --- Key: COLLECTIONS-479 URL: https://issues.apache.org/jira/browse/COLLECTIONS-479 Project: Commons Collections Issue Type: New Feature Reporter: Ajo Fod Priority: Minor Attachments: NodeExistsException.java, RedBlackBST.java An order statistic tree http://en.wikipedia.org/wiki/Order_statistic_tree provides two useful properties. The ability to rank arbitrary keys relative to keys existing in the tree AND the ability to retrieve elements from the tree with the given rank. This can be used to find the percentile rank of a key for example. This functionality is not yet provided yet by any of the major libraries AFAIK. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (COLLECTIONS-479) An Order Statistic Tree
[
https://issues.apache.org/jira/browse/COLLECTIONS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854440#comment-13854440
]
Rodion Efremov commented on COLLECTIONS-479:
What package should I put it in? Might
'{{org.apache.commons.collections4.map}}' be the right place?
An Order Statistic Tree
---
Key: COLLECTIONS-479
URL: https://issues.apache.org/jira/browse/COLLECTIONS-479
Project: Commons Collections
Issue Type: New Feature
Reporter: Ajo Fod
Priority: Minor
Attachments: NodeExistsException.java, RedBlackBST.java
An order statistic tree http://en.wikipedia.org/wiki/Order_statistic_tree
provides two useful properties. The ability to rank arbitrary keys relative
to keys existing in the tree AND the ability to retrieve elements from the
tree with the given rank.
This can be used to find the percentile rank of a key for example.
This functionality is not yet provided yet by any of the major libraries
AFAIK.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (MATH-1082) Existing cutOff mechanism in SimplexSolver can lead to wrong solutions
Thomas Neidhart created MATH-1082: - Summary: Existing cutOff mechanism in SimplexSolver can lead to wrong solutions Key: MATH-1082 URL: https://issues.apache.org/jira/browse/MATH-1082 Project: Commons Math Issue Type: Bug Reporter: Thomas Neidhart Fix For: 3.2 The cutOff mechanism introduced in MATH-828 does not work in call cases correctly. Tests with the example from netlib have shown that sometimes an invalid solution is returned because of this. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (LANG-637) There should be a DifferenceBuilder with a ReflectionDifferenceBuilder implementation
[ https://issues.apache.org/jira/browse/LANG-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854469#comment-13854469 ] Matt Benson commented on LANG-637: -- Hi, Duncan. After more than a year, I have now reviewed this. I personally would like to see DiffList implement ListDiff?, and then I would personally be in favor of committing this code. As long as it has been, I can understand if you've moved on and don't have time to make this change, in which case I can do it. There should be a DifferenceBuilder with a ReflectionDifferenceBuilder implementation - Key: LANG-637 URL: https://issues.apache.org/jira/browse/LANG-637 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Reporter: Eric Lewis Priority: Minor Fix For: Review Patch Attachments: Diff.java, DiffBuilder.java, DiffBuilderTest.java, DiffList.java, DiffListTest.java, DiffTest.java, Diffable.java, commons-lang3-LANG-637-complete.patch, commons-lang3-LANG-637.patch The ToStringBuilder and ReflectionToStringBuilder are great tools for everyday development. We use them to show all the properties in an object, which comes handy especially for testing. However, JUnit with its assertEquals() just outputs the toString() of the two compared objects. For complex objects, this becomes unreadable. So, it would be great to have a DifferenceBuilder with a ReflectionDifferenceBuilder implementation to be able to get only the differing properties of two objects. The question is whether the two objects would have to be of the same type or not. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (MATH-1082) Existing cutOff mechanism in SimplexSolver can lead to wrong solutions
[ https://issues.apache.org/jira/browse/MATH-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1082. --- Resolution: Fixed Fix Version/s: (was: 3.2) 3.3 Fixed in r1552792. Plan to include several unit tests when mps loader is finished. Existing cutOff mechanism in SimplexSolver can lead to wrong solutions -- Key: MATH-1082 URL: https://issues.apache.org/jira/browse/MATH-1082 Project: Commons Math Issue Type: Bug Reporter: Thomas Neidhart Fix For: 3.3 The cutOff mechanism introduced in MATH-828 does not work in call cases correctly. Tests with the example from netlib have shown that sometimes an invalid solution is returned because of this. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CODEC-174) Improve performance of Beider Morse encoder
[ https://issues.apache.org/jira/browse/CODEC-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved CODEC-174. Resolution: Fixed Fix Version/s: 1.9 Improve performance of Beider Morse encoder --- Key: CODEC-174 URL: https://issues.apache.org/jira/browse/CODEC-174 Project: Commons Codec Issue Type: Improvement Affects Versions: 1.6, 1.7 Reporter: Thomas Champagne Labels: patch, performance Fix For: 1.9 Attachments: CODEC-174-change-rules-storage-to-Map.patch, CODEC-174-convert-set-to-list-in-apply-method.patch, CODEC-174-delete-subsequence-cache-and-use-String.patch, CODEC-174-delete-subsequence-cache.patch, CODEC-174-refactor-join-method-in-Phoneme.patch, CODEC-174-refactor-restrictTo-method-in-SomeLanguages.patch, CODEC-174-reuse-set-in-PhonemeBuilder.patch, CODEC_174_cleanup.patch, TestCacheSubSequence.java, test-commons-codec-test-bm.zip I use Beider Morse encoder with Solr. When it indexes a lot of documents using this encoder, the import time is multiplied by 30. So, I have decided to optimize the current implementation in the commons-codec. Currently, I have created two patch. The first patch delete a performance hack about a subsequence cache. This cache doesn't optimize performance and after deleting it, you can win some milliseconds. The second patch changes the storage of the rules in memory using a Map instead of List. With it, you can access to a rule directly with the beginning of pattern. This patch divide the encoding time by 2. I will try to find more improvement. If you have any idea, please tell me it. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (OGNL-240) Non-determinsitic build unit test
Jason Pyeron created OGNL-240: - Summary: Non-determinsitic build unit test Key: OGNL-240 URL: https://issues.apache.org/jira/browse/OGNL-240 Project: Commons OGNL Issue Type: Bug Components: Core Runtime Affects Versions: 4.0 Environment: windows 64bit Reporter: Jason Pyeron Running org.apache.commons.ognl.test.MethodTest Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0 sec FAILURE! runTest[3](org.apache.commons.ognl.test.MethodTest) Time elapsed: 0 sec FAILURE! org.junit.ComparisonFailure: expected:f[oo] but was:f[irst] at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.commons.ognl.test.OgnlTestCase.assertEquals(OgnlTestCase.java:196) at org.apache.commons.ognl.test.OgnlTestCase.runTest(OgnlTestCase.java:217) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (OGNL-240) Non-determinsitic build unit test
[ https://issues.apache.org/jira/browse/OGNL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Pyeron updated OGNL-240: -- Attachment: TEST-org.apache.commons.ognl.test.MethodTest.xml unit test log file Non-determinsitic build unit test - Key: OGNL-240 URL: https://issues.apache.org/jira/browse/OGNL-240 Project: Commons OGNL Issue Type: Bug Components: Core Runtime Affects Versions: 4.0 Environment: windows 64bit Reporter: Jason Pyeron Attachments: TEST-org.apache.commons.ognl.test.MethodTest.xml Running org.apache.commons.ognl.test.MethodTest Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0 sec FAILURE! runTest[3](org.apache.commons.ognl.test.MethodTest) Time elapsed: 0 sec FAILURE! org.junit.ComparisonFailure: expected:f[oo] but was:f[irst] at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.commons.ognl.test.OgnlTestCase.assertEquals(OgnlTestCase.java:196) at org.apache.commons.ognl.test.OgnlTestCase.runTest(OgnlTestCase.java:217) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (OGNL-240) build unit test failure MethodTestOgnlTestCase.runTest:217-OgnlTestCase.assertEquals:196 expected:f[oo] but was:f[irst]
[ https://issues.apache.org/jira/browse/OGNL-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Pyeron updated OGNL-240: -- Summary: build unit test failure MethodTestOgnlTestCase.runTest:217-OgnlTestCase.assertEquals:196 expected:f[oo] but was:f[irst] (was: Non-determinsitic build unit test) build unit test failure MethodTestOgnlTestCase.runTest:217-OgnlTestCase.assertEquals:196 expected:f[oo] but was:f[irst] - Key: OGNL-240 URL: https://issues.apache.org/jira/browse/OGNL-240 Project: Commons OGNL Issue Type: Bug Components: Core Runtime Affects Versions: 4.0 Environment: windows 64bit Reporter: Jason Pyeron Attachments: TEST-org.apache.commons.ognl.test.MethodTest.xml Running org.apache.commons.ognl.test.MethodTest Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0 sec FAILURE! runTest[3](org.apache.commons.ognl.test.MethodTest) Time elapsed: 0 sec FAILURE! org.junit.ComparisonFailure: expected:f[oo] but was:f[irst] at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.commons.ognl.test.OgnlTestCase.assertEquals(OgnlTestCase.java:196) at org.apache.commons.ognl.test.OgnlTestCase.runTest(OgnlTestCase.java:217) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854802#comment-13854802 ] Henri Yandell commented on LANG-769: Not enough support for UnhandledException. Issue already closed. Please restore NotImplementedException and UnhandledException - Key: LANG-769 URL: https://issues.apache.org/jira/browse/LANG-769 Project: Commons Lang Issue Type: Improvement Components: lang.exception.* Reporter: david cogen Priority: Minor Fix For: 3.2 Why were these removed? I found these very useful and used them often. As the version 2.6 api javadoc states, This exception supplements the standard exception classes by providing a more semantically rich description of the problem. Just want you to realize that these have found direct use outside the library; not just internal use within commons-lang. I will define these missing classes myself, or maybe include both commons-lang and commons-lang3 (but I really don't to do that). It would be very nice to have these back. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
