[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-tabpanel&focusedCommentId=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)
[jira] [Updated] (OGNL-240) build unit test failure MethodTest>OgnlTestCase.runTest:217->OgnlTestCase.assertEquals:196 expected: but was:
[ 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 MethodTest>OgnlTestCase.runTest:217->OgnlTestCase.assertEquals:196 expected: but was: (was: Non-determinsitic build unit test) > build unit test failure > MethodTest>OgnlTestCase.runTest:217->OgnlTestCase.assertEquals:196 > expected: but was: > - > > 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: but was: > 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: but was: > 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] [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: but was: 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] [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] [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] [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-tabpanel&focusedCommentId=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 List>, 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] [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] (COLLECTIONS-479) An Order Statistic Tree
[
https://issues.apache.org/jira/browse/COLLECTIONS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (COLLECTIONS-479) An Order Statistic Tree
[ https://issues.apache.org/jira/browse/COLLECTIONS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] (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-tabpanel&focusedCommentId=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] [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] [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] [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-tabpanel&focusedCommentId=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] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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] (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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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] [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-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-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-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
> topdirectory/p
[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-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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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] [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-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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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)
