[jira] [Commented] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933125#comment-16933125
]
Stefan Bodewig commented on COMPRESS-494:
-
This exception is thrown if {{setSize}} is invoked with a negative value,
pretty much independent of the version of Commons Compress.
[~anveshmora] is there any chance you could provide an archive that causes this
so we can have a look ourselves?
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.8, 1.18
>Reporter: Anvesh Mora
>Priority: Critical
> Fix For: 1.8, 1.18
>
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
> I missed to add version info, below are those:
> version of lib I'm using is: 1.9
> And I did try version 1.18, issue is observed in this version too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933127#comment-16933127
]
Stefan Bodewig commented on COMPRESS-494:
-
BTW so far I've been under the impression "Fix Version/s" would be the version
that the issue has been fixed in - and used it like that. If my interpretation
is correct than it should not be set at all right now. If I'm wrong than I'd
like to be educated :)
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.8, 1.18
>Reporter: Anvesh Mora
>Priority: Critical
> Fix For: 1.8, 1.18
>
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
> I missed to add version info, below are those:
> version of lib I'm using is: 1.9
> And I did try version 1.18, issue is observed in this version too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen commented on COLLECTIONS-714:
--
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 9:14 AM:
---
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.selectKey("x").equals("x\u")); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 9:15 AM:
---
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue("x\u".equals(trie.selectKey("x"))); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.selectKey("x").equals("x\u")); // fail
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 9:16 AM:
---
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
If need, i will provide a PR on github.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue("x\u".equals(trie.selectKey("x"))); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye] [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue("x\u".equals(trie.selectKey("x"))); // fail
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933239#comment-16933239
]
Gary Gregory commented on COMPRESS-494:
---
Oops that's my fault. I meant to say "*Affects Version/s:"*
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.8, 1.18
>Reporter: Anvesh Mora
>Priority: Critical
> Fix For: 1.8, 1.18
>
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
> I missed to add version info, below are those:
> version of lib I'm using is: 1.9
> And I did try version 1.18, issue is observed in this version too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anvesh Mora updated COMPRESS-494:
-
Fix Version/s: (was: 1.18)
(was: 1.8)
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.8, 1.18
>Reporter: Anvesh Mora
>Priority: Critical
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
> I missed to add version info, below are those:
> version of lib I'm using is: 1.9
> And I did try version 1.18, issue is observed in this version too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933244#comment-16933244
]
Anvesh Mora commented on COMPRESS-494:
--
[~bodewig] I can confirm on sharing archive once I discuss my team and
business. We except to have logs with sensitive information. I'll update it
here after discussion. I'm sure we can figure out something on this.
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.8, 1.18
>Reporter: Anvesh Mora
>Priority: Critical
> Fix For: 1.8, 1.18
>
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
> I missed to add version info, below are those:
> version of lib I'm using is: 1.9
> And I did try version 1.18, issue is observed in this version too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DAEMON-408) PROCRUN 1.2.x x64 crash on Windows Server 2008 R2
Simon Wimmesberger created DAEMON-408: - Summary: PROCRUN 1.2.x x64 crash on Windows Server 2008 R2 Key: DAEMON-408 URL: https://issues.apache.org/jira/browse/DAEMON-408 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.2.0, 1.2.1 Reporter: Simon Wimmesberger Since procrun version 1.2.0 the application crashes when executed on Windows Server 2008 R2: Problemsignatur: Error name: BEX64 Application name: procrun.exe Application version: 1.2.1.0 Application timestamp: 5d6fdd78 Error module name: StackHash_25f1 Error module version: 0.0.0.0 Error module timestamp: Error offset: 004f8aa2 Error code: c005 Error data: 0008 OS Version: 6.1.7600.2.0.0.1296.17 Additional info 1: 25f1 Additional info 2: 25f1bf9a72a93f5658ee9429e86c7409 Additional info 3: f2ca Additional info 4: f2ca14b6934ede5b7e664f76bc87ba68 I also have a crash dump available but for security/sensitive reasons I will only provide it privately when necessary. With version 1.1.0 I can't reproduce the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DAEMON-408) PROCRUN 1.2.x x64 crash on Windows Server 2008 R2
[ https://issues.apache.org/jira/browse/DAEMON-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Wimmesberger updated DAEMON-408: -- Description: Since procrun version 1.2.0 the application crashes when executed on Windows Server 2008 R2: Problemsignatur: Problem Event Name: BEX64 Application Name: procrun.exe Application Version: 1.2.1.0 Application Timestamp: 5d6fdd78 Fault Module Name: StackHash_25f1 Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Offset: 004f8aa2 Exception Code: c005 Exception Data: 0008 OS Version: 6.1.7600.2.0.0.1296.17 Additional Information 1: 25f1 Additional Information 2: 25f1bf9a72a93f5658ee9429e86c7409 Additional Information 3: f2ca Additional Information 4: f2ca14b6934ede5b7e664f76bc87ba68 I also have a crash dump available but for security/sensitive reasons I will only provide it privately when necessary. With version 1.1.0 I can't reproduce the issue. was: Since procrun version 1.2.0 the application crashes when executed on Windows Server 2008 R2: Problemsignatur: Error name: BEX64 Application name: procrun.exe Application version: 1.2.1.0 Application timestamp: 5d6fdd78 Error module name: StackHash_25f1 Error module version: 0.0.0.0 Error module timestamp: Error offset: 004f8aa2 Error code: c005 Error data: 0008 OS Version: 6.1.7600.2.0.0.1296.17 Additional info 1: 25f1 Additional info 2: 25f1bf9a72a93f5658ee9429e86c7409 Additional info 3: f2ca Additional info 4: f2ca14b6934ede5b7e664f76bc87ba68 I also have a crash dump available but for security/sensitive reasons I will only provide it privately when necessary. With version 1.1.0 I can't reproduce the issue. > PROCRUN 1.2.x x64 crash on Windows Server 2008 R2 > - > > Key: DAEMON-408 > URL: https://issues.apache.org/jira/browse/DAEMON-408 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.0, 1.2.1 >Reporter: Simon Wimmesberger >Priority: Major > > Since procrun version 1.2.0 the application crashes when executed on Windows > Server 2008 R2: > Problemsignatur: > Problem Event Name: BEX64 > Application Name: procrun.exe > Application Version: 1.2.1.0 > Application Timestamp: 5d6fdd78 > Fault Module Name: StackHash_25f1 > Fault Module Version: 0.0.0.0 > Fault Module Timestamp: > Exception Offset: 004f8aa2 > Exception Code: c005 > Exception Data: 0008 > OS Version: 6.1.7600.2.0.0.1296.17 > Additional Information 1: 25f1 > Additional Information 2: 25f1bf9a72a93f5658ee9429e86c7409 > Additional Information 3: f2ca > Additional Information 4: f2ca14b6934ede5b7e664f76bc87ba68 > > I also have a crash dump available but for security/sensitive reasons I will > only provide it privately when necessary. > > With version 1.1.0 I can't reproduce the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 1:27 PM:
---
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
If need, i will provide a PR on github.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
but, when run testNullTerminatedKey2, trie.containsKey("x") fail.
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x\u")); // ok
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
If need, i will provide a PR on github.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
testNullTerminatedKey2
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue("x\u".equals(trie.selectKey("x"))); // fail
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933188#comment-16933188
]
Chen edited comment on COLLECTIONS-714 at 9/19/19 1:27 PM:
---
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
but, when run testNullTerminatedKey2, trie.containsKey("x") fail.
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x\u")); // ok
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
was (Author: guoping1):
Hi, [~rohanpadhye], [~ggregory]
This problem is case by StringKeyAnalyzer#bitIndex don't support \u.
Because k=0=f=\u, so there should not use k!=f.
I think when index1>=endIndex1, we should set some sign instead of setting k=0,
then use the sign to instead of k!=f.
If need, i will provide a PR on github.
{code:java}
if (index1 >= endIndex1) {
k = 0;
} else {
k = key.charAt(index1);
}
if (other == null || index2 >= endIndex2) {
f = 0;
fflag = true;
} else {
f = other.charAt(index2);
}
if ( (k != f ) {
final int x = k ^ f;
return i * LENGTH + Integer.numberOfLeadingZeros(x) - LENGTH;
}
{code}
but, when run testNullTerminatedKey2, trie.containsKey("x") fail.
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x\u")); // ok
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933426#comment-16933426
]
Gary Gregory commented on COLLECTIONS-714:
--
The current PR fails:
{noformat}
[ERROR] Failures:
[ERROR] PatriciaTrieTest.testNullTerminatedKey1:440 expected:<3> but was:<2>
[ERROR] PatriciaTrieTest.testNullTerminatedKey2:451
[INFO]
[ERROR] Tests run: 24948, Failures: 2, Errors: 0, Skipped: 0
{noformat}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-csv] macsharker6 commented on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames
macsharker6 commented on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames URL: https://github.com/apache/commons-csv/pull/43#issuecomment-533182150 Hi @garydgregory any update for the release 1.8? Thanks. macsharker6 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-net] Umoxfo commented on a change in pull request #41: [NET-405] Support for IPv6 in SubnetUtils
Umoxfo commented on a change in pull request #41: [NET-405] Support for IPv6 in
SubnetUtils
URL: https://github.com/apache/commons-net/pull/41#discussion_r326285270
##
File path: src/main/java/org/apache/commons/net/util/SubnetUtils.java
##
@@ -16,348 +16,344 @@
*/
package org.apache.commons.net.util;
-import java.util.regex.Matcher;
import java.util.regex.Pattern;
/**
- * A class that performs some subnet calculations given a network address and
a subnet mask.
- * @see "http://www.faqs.org/rfcs/rfc1519.html";
+ * This class that performs some subnet calculations given IP address in
CIDR-notation.
+ * For IPv4 address subnet, especially Classless Inter-Domain Routing
(CIDR),
+ * refer to https://tools.ietf.org/html/rfc4632";>RFC4632.
+ * For IPv6 address subnet, refer to https://tools.ietf.org/html/rfc4291#section-2.3";>
+ * Section 2.3 of RFC 4291.
+ *
* @since 2.0
*/
-public class SubnetUtils {
-
-private static final String IP_ADDRESS =
"(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})";
-private static final String SLASH_FORMAT = IP_ADDRESS + "/(\\d{1,2})"; //
0 -> 32
-private static final Pattern addressPattern = Pattern.compile(IP_ADDRESS);
-private static final Pattern cidrPattern = Pattern.compile(SLASH_FORMAT);
-private static final int NBITS = 32;
-
-private final int netmask;
-private final int address;
-private final int network;
-private final int broadcast;
-
-/** Whether the broadcast/network address are included in host count */
-private boolean inclusiveHostCount = false;
-
+public class SubnetUtils
+{
+
+private static final String IPV4_ADDRESS =
"(\\d{1,3}\\.){3}\\d{1,3}/\\d{1,2}";
+private static final String IPV6_ADDRESS =
"(([0-9a-f]{1,4}:){7}[0-9a-f]{1,4}|"
+ + "([0-9a-f]{1,4}:){1,7}:|"
+ +
"([0-9a-f]{1,4}:){1,6}:[0-9a-f]{1,4}|"
+ +
"([0-9a-f]{1,4}:){1,5}(:[0-9a-f]{1,4}){1,2}|"
+ +
"([0-9a-f]{1,4}:){1,4}(:[0-9a-f]{1,4}){1,3}|"
+ +
"([0-9a-f]{1,4}:){1,3}(:[0-9a-f]{1,4}){1,4}|"
+ +
"([0-9a-f]{1,4}:){1,2}(:[0-9a-f]{1,4}){1,5}|"
+ +
"[0-9a-f]{1,4}:((:[0-9a-f]{1,4}){1,6})|"
+ +
":((:[0-9a-f]{1,4}){1,7}|:))/\\d{1,3}";
+
+private final SubnetInfo subnetInfo;
/**
- * Constructor that takes a CIDR-notation string, e.g. "192.168.0.1/16"
- * @param cidrNotation A CIDR-notation string, e.g. "192.168.0.1/16"
+ * Constructor that creates subnet summary information based on the
provided IPv4 or IPv6 address in CIDR-notation,
+ * e.g. "192.168.0.1/16" or "2001:db8:0:0:0:ff00:42:8329/46"
+ *
+ * NOTE: IPv6 address does NOT allow to omit consecutive sections of zeros
in the current version.
+ *
+ * @param cidrNotation IPv4 or IPv6 address, e.g. "192.168.0.1/16" or
"2001:db8:0:0:0:ff00:42:8329/46"
* @throws IllegalArgumentException if the parameter is invalid,
- * i.e. does not match n.n.n.n/m where n=1-3 decimal digits, m = 1-2
decimal digits in range 0-32
+ * e.g. does not match either n.n.n.n/m where n = 1-3 decimal digits, m =
1-2 decimal digits in range 0-32; or
+ * n:n:n:n:n:n:n:n/m n = 1-4 hexadecimal digits, m = 1-3 decimal digits in
range 0-128.
*/
-public SubnetUtils(String cidrNotation) {
- Matcher matcher = cidrPattern.matcher(cidrNotation);
-
- if (matcher.matches()) {
- this.address = matchAddress(matcher);
-
- /* Create a binary netmask from the number of bits specification /x
*/
-
- int trailingZeroes = NBITS -
rangeCheck(Integer.parseInt(matcher.group(5)), 0, NBITS);
- /*
- * An IPv4 netmask consists of 32 bits, a contiguous sequence
- * of the specified number of ones followed by all zeros.
- * So, it can be obtained by shifting an unsigned integer (32 bits)
to the left by
- * the number of trailing zeros which is (32 - the # bits
specification).
- * Note that there is no unsigned left shift operator, so we have to
use
- * a long to ensure that the left-most bit is shifted out correctly.
- */
- this.netmask = (int) (0x0L << trailingZeroes );
-
- /* Calculate base network address */
- this.network = (address & netmask);
-
- /* Calculate broadcast address */
- this.broadcast = network | ~(netmask);
- } else {
- throw new IllegalArgumentException("Could not parse [" +
cidrNotation + "]");
- }
+public SubnetUtils(String cidrNotation)
+{
+subnetInfo = getByCIDRNotation(cidrNotation);
}
/**
- * Constructor that takes a dotted
[GitHub] [commons-net] Umoxfo commented on a change in pull request #41: [NET-405] Support for IPv6 in SubnetUtils
Umoxfo commented on a change in pull request #41: [NET-405] Support for IPv6 in
SubnetUtils
URL: https://github.com/apache/commons-net/pull/41#discussion_r326285017
##
File path: src/main/java/org/apache/commons/net/util/IP6Subnet.java
##
@@ -0,0 +1,288 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.net.util;
+
+import java.math.BigInteger;
+
+/**
+ * Convenience container for IPv6 subnet summary information.
+ *
+ * @see https://tools.ietf.org/html/rfc4291#section-2.3";>https://tools.ietf.org/html/rfc4291#section-2.3
+ * @since 3.7
+ */
+public final class IP6Subnet extends SubnetUtils.SubnetInfo
+{
+
+private static final int NBITS = 128;
+
+private final int[] ip6Address;
+private final int cidr;
+
+/**
+ * Constructor that takes an IPv6 address in CIDR-notation, e.g.
"2001:db8:0:0:0:ff00:42:8329/48".
+ *
+ * @param cidrNotation an IPv6 address in CIDR-notation
+ */
+public IP6Subnet(String cidrNotation)
+{
+String[] tmp = cidrNotation.split("/");
+
+ip6Address = toArray(tmp[0]);
Review comment:
Any shorthand IPv6 address formats are not supported.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-lang] garydgregory commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on a change in pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r326441799
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -47,7 +47,7 @@
* Unit tests {@link org.apache.commons.lang3.ClassUtils}.
*/
@SuppressWarnings("boxing") // JUnit4 does not support primitive equality
testing apart from long
-public class ClassUtilsTest {
+class ClassUtilsTest {
Review comment:
@verhas ping.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-lang] garydgregory commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on a change in pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r326441764
##
File path: src/main/java/org/apache/commons/lang3/ClassUtils.java
##
@@ -433,48 +440,83 @@ public static String getAbbreviatedName(final Class
cls, final int len) {
* "java.lang.String" 5"j.l.String"
* "java.lang.String"15"j.lang.String"
*
"java.lang.String"30"java.lang.String"
+ *
"org.apache.commons.lang3.ClassUtils"18"o.a.c.l.ClassUtils"
*
- * @param className the className to get the abbreviated name for, may be
{@code null}
- * @param len the desired length of the abbreviated name
- * @return the abbreviated name or an empty string
- * @throws IllegalArgumentException if len <= 0
+ *
+ * @param className the className to get the abbreviated name for, may be
{@code null}
+ * @param len the desired length of the abbreviated name
+ * @return the abbreviated name or an empty string if the specified
+ * class name is {@code null} or empty string. The abbreviated name may be
+ * longer than the desired length if it cannot be abbreviated to the
desired length.
+ * @throws IllegalArgumentException if {@code len <= 0}
* @since 3.4
*/
public static String getAbbreviatedName(final String className, final int
len) {
- if (len <= 0) {
-throw new IllegalArgumentException("len must be > 0");
- }
- if (className == null) {
-return StringUtils.EMPTY;
- }
-
- int availableSpace = len;
- final int packageLevels = StringUtils.countMatches(className, '.');
- final String[] output = new String[packageLevels + 1];
- int endIndex = className.length() - 1;
- for (int level = packageLevels; level >= 0; level--) {
-final int startIndex = className.lastIndexOf('.', endIndex);
-final String part = className.substring(startIndex + 1, endIndex + 1);
-availableSpace -= part.length();
-if (level > 0) {
- // all elements except top level require an additional char space
- availableSpace--;
+if (len <= 0) {
+throw new IllegalArgumentException("len must be > 0");
}
-if (level == packageLevels) {
- // ClassName is always complete
- output[level] = part;
-} else {
- if (availableSpace > 0) {
-output[level] = part;
- } else {
-// if no space is left still the first char is used
-output[level] = part.substring(0, 1);
- }
+if (className == null) {
+return StringUtils.EMPTY;
}
Review comment:
@verhas Then please go ahead and update the code and add a test.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-lang] garydgregory commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on a change in pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r326441672
##
File path: src/main/java/org/apache/commons/lang3/ClassUtils.java
##
@@ -433,48 +440,83 @@ public static String getAbbreviatedName(final Class
cls, final int len) {
* "java.lang.String" 5"j.l.String"
* "java.lang.String"15"j.lang.String"
*
"java.lang.String"30"java.lang.String"
+ *
"org.apache.commons.lang3.ClassUtils"18"o.a.c.l.ClassUtils"
*
- * @param className the className to get the abbreviated name for, may be
{@code null}
- * @param len the desired length of the abbreviated name
- * @return the abbreviated name or an empty string
- * @throws IllegalArgumentException if len <= 0
+ *
+ * @param className the className to get the abbreviated name for, may be
{@code null}
+ * @param len the desired length of the abbreviated name
+ * @return the abbreviated name or an empty string if the specified
+ * class name is {@code null} or empty string. The abbreviated name may be
+ * longer than the desired length if it cannot be abbreviated to the
desired length.
+ * @throws IllegalArgumentException if {@code len <= 0}
* @since 3.4
*/
public static String getAbbreviatedName(final String className, final int
len) {
Review comment:
@verhas Then please go ahead and change it to `lengthHint`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=315403&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-315403
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 20/Sep/19 01:28
Start Date: 20/Sep/19 01:28
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r326441799
##
File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
##
@@ -47,7 +47,7 @@
* Unit tests {@link org.apache.commons.lang3.ClassUtils}.
*/
@SuppressWarnings("boxing") // JUnit4 does not support primitive equality
testing apart from long
-public class ClassUtilsTest {
+class ClassUtilsTest {
Review comment:
@verhas ping.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 315403)
Remaining Estimate: 18h 50m (was: 19h)
Time Spent: 5h 10m (was: 5h)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 5h 10m
> Remaining Estimate: 18h 50m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=315404&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-315404
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 20/Sep/19 01:28
Start Date: 20/Sep/19 01:28
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r326441764
##
File path: src/main/java/org/apache/commons/lang3/ClassUtils.java
##
@@ -433,48 +440,83 @@ public static String getAbbreviatedName(final Class
cls, final int len) {
* "java.lang.String" 5"j.l.String"
* "java.lang.String"15"j.lang.String"
*
"java.lang.String"30"java.lang.String"
+ *
"org.apache.commons.lang3.ClassUtils"18"o.a.c.l.ClassUtils"
*
- * @param className the className to get the abbreviated name for, may be
{@code null}
- * @param len the desired length of the abbreviated name
- * @return the abbreviated name or an empty string
- * @throws IllegalArgumentException if len <= 0
+ *
+ * @param className the className to get the abbreviated name for, may be
{@code null}
+ * @param len the desired length of the abbreviated name
+ * @return the abbreviated name or an empty string if the specified
+ * class name is {@code null} or empty string. The abbreviated name may be
+ * longer than the desired length if it cannot be abbreviated to the
desired length.
+ * @throws IllegalArgumentException if {@code len <= 0}
* @since 3.4
*/
public static String getAbbreviatedName(final String className, final int
len) {
- if (len <= 0) {
-throw new IllegalArgumentException("len must be > 0");
- }
- if (className == null) {
-return StringUtils.EMPTY;
- }
-
- int availableSpace = len;
- final int packageLevels = StringUtils.countMatches(className, '.');
- final String[] output = new String[packageLevels + 1];
- int endIndex = className.length() - 1;
- for (int level = packageLevels; level >= 0; level--) {
-final int startIndex = className.lastIndexOf('.', endIndex);
-final String part = className.substring(startIndex + 1, endIndex + 1);
-availableSpace -= part.length();
-if (level > 0) {
- // all elements except top level require an additional char space
- availableSpace--;
+if (len <= 0) {
+throw new IllegalArgumentException("len must be > 0");
}
-if (level == packageLevels) {
- // ClassName is always complete
- output[level] = part;
-} else {
- if (availableSpace > 0) {
-output[level] = part;
- } else {
-// if no space is left still the first char is used
-output[level] = part.substring(0, 1);
- }
+if (className == null) {
+return StringUtils.EMPTY;
}
Review comment:
@verhas Then please go ahead and update the code and add a test.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 315404)
Remaining Estimate: 18h 50m (was: 19h)
Time Spent: 5h 10m (was: 5h)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 5h 10m
> Remaining Estimate: 18h 50m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=315405&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-315405
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 20/Sep/19 01:28
Start Date: 20/Sep/19 01:28
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#discussion_r326441672
##
File path: src/main/java/org/apache/commons/lang3/ClassUtils.java
##
@@ -433,48 +440,83 @@ public static String getAbbreviatedName(final Class
cls, final int len) {
* "java.lang.String" 5"j.l.String"
* "java.lang.String"15"j.lang.String"
*
"java.lang.String"30"java.lang.String"
+ *
"org.apache.commons.lang3.ClassUtils"18"o.a.c.l.ClassUtils"
*
- * @param className the className to get the abbreviated name for, may be
{@code null}
- * @param len the desired length of the abbreviated name
- * @return the abbreviated name or an empty string
- * @throws IllegalArgumentException if len <= 0
+ *
+ * @param className the className to get the abbreviated name for, may be
{@code null}
+ * @param len the desired length of the abbreviated name
+ * @return the abbreviated name or an empty string if the specified
+ * class name is {@code null} or empty string. The abbreviated name may be
+ * longer than the desired length if it cannot be abbreviated to the
desired length.
+ * @throws IllegalArgumentException if {@code len <= 0}
* @since 3.4
*/
public static String getAbbreviatedName(final String className, final int
len) {
Review comment:
@verhas Then please go ahead and change it to `lengthHint`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 315405)
Remaining Estimate: 18h 50m (was: 19h)
Time Spent: 5h 10m (was: 5h)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 5h 10m
> Remaining Estimate: 18h 50m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] garydgregory commented on a change in pull request #84: [COLLECTIONS 708] Add hashCode method to CollectionUtils
garydgregory commented on a change in pull request #84: [COLLECTIONS 708] Add hashCode method to CollectionUtils URL: https://github.com/apache/commons-collections/pull/84#discussion_r326442217 ## File path: src/main/java/org/apache/commons/collections4/CollectionUtils.java ## @@ -608,6 +608,33 @@ public static boolean isEqualCollection(final Collection a, final Collection< return isEqualCollection(collect(a, transformer), collect(b, transformer)); } + +/** + * Getting the hashCode of Collection through the hash method of Equator. Review comment: Please replace `Getting the hashCode` with `Returns the hash code`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-collections] garydgregory commented on a change in pull request #84: [COLLECTIONS 708] Add hashCode method to CollectionUtils
garydgregory commented on a change in pull request #84: [COLLECTIONS 708] Add hashCode method to CollectionUtils URL: https://github.com/apache/commons-collections/pull/84#discussion_r326442291 ## File path: src/main/java/org/apache/commons/collections4/CollectionUtils.java ## @@ -608,6 +608,33 @@ public static boolean isEqualCollection(final Collection a, final Collection< return isEqualCollection(collect(a, transformer), collect(b, transformer)); } + +/** + * Getting the hashCode of Collection through the hash method of Equator. + * + * If the input collection is null return 1. + * + * + * @param the element type + * @param collection the input collection + * @param equator the Equator used for generate hashCode + * @return the hashCode of Collection through the hash method of Equator + */ Review comment: Please add a `@since` tag since this a new public method. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-collections] garydgregory commented on a change in pull request #84: [COLLECTIONS 708] Add hashCode method to CollectionUtils
garydgregory commented on a change in pull request #84: [COLLECTIONS 708] Add
hashCode method to CollectionUtils
URL: https://github.com/apache/commons-collections/pull/84#discussion_r326442342
##
File path: src/main/java/org/apache/commons/collections4/CollectionUtils.java
##
@@ -608,6 +608,33 @@ public static boolean isEqualCollection(final
Collection a, final Collection<
return isEqualCollection(collect(a, transformer), collect(b,
transformer));
}
+
+/**
+ * Getting the hashCode of Collection through the hash method of Equator.
+ *
+ * If the input collection is null return 1.
+ *
+ *
+ * @param the element type
+ * @param collection the input collection
+ * @param equator the Equator used for generate hashCode
+ * @return the hashCode of Collection through the hash method of Equator
+ */
+public static int hashCode(final Collection collection,
+ final Equator equator) {
+if (null == equator) {
+throw new NullPointerException( "Equator must not be null." );
+}
+if (null == collection) {
+return 1;
+}
+int hashCode = 1;
+for (final E e : collection) {
+
Review comment:
Remove this extra blank line please.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
