[GitHub] [commons-net] sawantnitesh commented on pull request #90: NET-642 using execPROT on FTPSClients with Proxy Settings removes Pro…
sawantnitesh commented on PR #90: URL: https://github.com/apache/commons-net/pull/90#issuecomment-1088261758 Will it be merged. We are blocked because of this issue to migrate to Commons NET. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-670) IOUtils.contentEquals is of low performance. I will refine it.
[ https://issues.apache.org/jira/browse/IO-670?focusedWorklogId=752500=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752500 ] ASF GitHub Bot logged work on IO-670: - Author: ASF GitHub Bot Created on: 04/Apr/22 20:32 Start Date: 04/Apr/22 20:32 Worklog Time Spent: 10m Work Description: XenoAmess commented on PR #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-1087986166 @garydgregory rebased. now passed new checkstyle. Issue Time Tracking --- Worklog Id: (was: 752500) Time Spent: 15h (was: 14h 50m) > IOUtils.contentEquals is of low performance. I will refine it. > -- > > Key: IO-670 > URL: https://issues.apache.org/jira/browse/IO-670 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Critical > Attachments: jmh-result.org.apache.json > > Time Spent: 15h > Remaining Estimate: 0h > > [https://github.com/apache/commons-io/pull/118] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-io] XenoAmess commented on pull request #118: [IO-670] refine IOUtils.contentEqualsIgnoreEOL(Reader, Reader)
XenoAmess commented on PR #118: URL: https://github.com/apache/commons-io/pull/118#issuecomment-1087986166 @garydgregory rebased. now passed new checkstyle. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory commented on pull request #66: Avoid Code Duplication: Reuse Sleep from ThreadMonitor
garydgregory commented on PR #66: URL: https://github.com/apache/commons-io/pull/66#issuecomment-1087948406 @DaGeRe 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory closed pull request #293: Refactor `ReaderInputStream` implementation
garydgregory closed pull request #293: Refactor `ReaderInputStream` implementation URL: https://github.com/apache/commons-io/pull/293 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory commented on pull request #293: Refactor `ReaderInputStream` implementation
garydgregory commented on PR #293: URL: https://github.com/apache/commons-io/pull/293#issuecomment-1087947634 Closing, no feedback. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory commented on pull request #131: new test copyFileWrongPermissions
garydgregory commented on PR #131: URL: https://github.com/apache/commons-io/pull/131#issuecomment-1087947335 Closing, no feedback. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory closed pull request #131: new test copyFileWrongPermissions
garydgregory closed pull request #131: new test copyFileWrongPermissions URL: https://github.com/apache/commons-io/pull/131 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-680) add more tests for IOUtils.contentEqualsIgnoreEOL
[ https://issues.apache.org/jira/browse/IO-680?focusedWorklogId=752478=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752478 ] ASF GitHub Bot logged work on IO-680: - Author: ASF GitHub Bot Created on: 04/Apr/22 19:45 Start Date: 04/Apr/22 19:45 Worklog Time Spent: 10m Work Description: garydgregory merged PR #137: URL: https://github.com/apache/commons-io/pull/137 Issue Time Tracking --- Worklog Id: (was: 752478) Time Spent: 2h 20m (was: 2h 10m) > add more tests for IOUtils.contentEqualsIgnoreEOL > - > > Key: IO-680 > URL: https://issues.apache.org/jira/browse/IO-680 > Project: Commons IO > Issue Type: Test >Reporter: Jin Xu >Priority: Minor > Time Spent: 2h 20m > Remaining Estimate: 0h > > [https://github.com/apache/commons-io/pull/137] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-io] garydgregory merged pull request #137: [IO-680] add more tests for IOUtils.contentEqualsIgnoreEOL
garydgregory merged PR #137: URL: https://github.com/apache/commons-io/pull/137 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-764) IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?focusedWorklogId=752467=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752467
]
ASF GitHub Bot logged work on IO-764:
-
Author: ASF GitHub Bot
Created on: 04/Apr/22 19:35
Start Date: 04/Apr/22 19:35
Worklog Time Spent: 10m
Work Description: garydgregory commented on code in PR #343:
URL: https://github.com/apache/commons-io/pull/343#discussion_r842076125
##
src/test/java/org/apache/commons/io/IOUtilsTest.java:
##
@@ -1643,5 +1644,19 @@ public void testToString_URL_CharsetName() throws
Exception {
public void testToString_URL_CharsetNameNull() throws Exception {
testToString_URL(null);
}
+
+@Test
+public void testBigString() throws IOException {
+ String foo = StringUtils.repeat("\uD83D", (Integer.MAX_VALUE)/2-1);
Review Comment:
> No shared CI will provide you these resources.
Hi @michael-o
I wrote a different version of the test that is less resource-intensive and
more lenient. See git master. The main code is still broken though.
Issue Time Tracking
---
Worklog Id: (was: 752467)
Time Spent: 1h (was: 50m)
> IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while
> writing big strings
>
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-io] garydgregory commented on a diff in pull request #343: IO-764 Fix big string writing by writing with ByteBuffer instead calling getBytes directly
garydgregory commented on code in PR #343:
URL: https://github.com/apache/commons-io/pull/343#discussion_r842076125
##
src/test/java/org/apache/commons/io/IOUtilsTest.java:
##
@@ -1643,5 +1644,19 @@ public void testToString_URL_CharsetName() throws
Exception {
public void testToString_URL_CharsetNameNull() throws Exception {
testToString_URL(null);
}
+
+@Test
+public void testBigString() throws IOException {
+ String foo = StringUtils.repeat("\uD83D", (Integer.MAX_VALUE)/2-1);
Review Comment:
> No shared CI will provide you these resources.
Hi @michael-o
I wrote a different version of the test that is less resource-intensive and
more lenient. See git master. The main code is still broken though.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-1677) It should be possible to exclude fields in ReflectionDiffBuilder
[ https://issues.apache.org/jira/browse/LANG-1677?focusedWorklogId=752465=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752465 ] ASF GitHub Bot logged work on LANG-1677: Author: ASF GitHub Bot Created on: 04/Apr/22 19:32 Start Date: 04/Apr/22 19:32 Worklog Time Spent: 10m Work Description: debae commented on code in PR #838: URL: https://github.com/apache/commons-lang/pull/838#discussion_r842074232 ## src/changes/changes.xml: ## @@ -66,6 +66,7 @@ The type attribute can be add,update,fix,remove. Use Set instead of List for checking the contains() method #734. Javadoc for StringUtils.substringBefore(String str, int separator) doesn't mention that the separator is an int. It should be possible to exclude fields in ReflectionDiffBuilder > > > Key: LANG-1677 > URL: https://issues.apache.org/jira/browse/LANG-1677 > Project: Commons Lang > Issue Type: Wish > Components: lang.builder.* >Affects Versions: 3.12.0 >Reporter: Dennis Baerten >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > When using ReflectionDiffBuilder to make a diff between two object it will be > default include all fields. As stated in the documentation static and > transient fields are excluded. > Using the transient modifier in combination with other frameworks ( such as > Hibernate ) also has a side affect that those fields are not persisted. > The use case I'm trying to solve it making a diff of an object that get's > updated and has a LastModificationDate and LastModificationUser and thus will > always be a field in the diff. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-lang] debae commented on a diff in pull request #838: LANG-1677 : Add ReflectionDiffBuilder.setExcludeFieldNames(...) and DiffExclude a…
debae commented on code in PR #838: URL: https://github.com/apache/commons-lang/pull/838#discussion_r842074232 ## src/changes/changes.xml: ## @@ -66,6 +66,7 @@ The type attribute can be add,update,fix,remove. Use Set instead of List for checking the contains() method #734. Javadoc for StringUtils.substringBefore(String str, int separator) doesn't mention that the separator is an int. +Add ReflectionDiffBuilder.setExcludeFieldNames(...) and DiffExclude annotation to support field exclusion from diff. Review Comment: Removed the file again. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory merged pull request #342: Bump jmh.version from 1.34 to 1.35
garydgregory merged PR #342: URL: https://github.com/apache/commons-io/pull/342 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1677) It should be possible to exclude fields in ReflectionDiffBuilder
[ https://issues.apache.org/jira/browse/LANG-1677?focusedWorklogId=752428=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752428 ] ASF GitHub Bot logged work on LANG-1677: Author: ASF GitHub Bot Created on: 04/Apr/22 18:31 Start Date: 04/Apr/22 18:31 Worklog Time Spent: 10m Work Description: garydgregory commented on code in PR #838: URL: https://github.com/apache/commons-lang/pull/838#discussion_r842029947 ## src/changes/changes.xml: ## @@ -66,6 +66,7 @@ The type attribute can be add,update,fix,remove. Use Set instead of List for checking the contains() method #734. Javadoc for StringUtils.substringBefore(String str, int separator) doesn't mention that the separator is an int. It should be possible to exclude fields in ReflectionDiffBuilder > > > Key: LANG-1677 > URL: https://issues.apache.org/jira/browse/LANG-1677 > Project: Commons Lang > Issue Type: Wish > Components: lang.builder.* >Affects Versions: 3.12.0 >Reporter: Dennis Baerten >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > When using ReflectionDiffBuilder to make a diff between two object it will be > default include all fields. As stated in the documentation static and > transient fields are excluded. > Using the transient modifier in combination with other frameworks ( such as > Hibernate ) also has a side affect that those fields are not persisted. > The use case I'm trying to solve it making a diff of an object that get's > updated and has a LastModificationDate and LastModificationUser and thus will > always be a field in the diff. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-lang] garydgregory commented on a diff in pull request #838: LANG-1677 : Add ReflectionDiffBuilder.setExcludeFieldNames(...) and DiffExclude a…
garydgregory commented on code in PR #838: URL: https://github.com/apache/commons-lang/pull/838#discussion_r842029947 ## src/changes/changes.xml: ## @@ -66,6 +66,7 @@ The type attribute can be add,update,fix,remove. Use Set instead of List for checking the contains() method #734. Javadoc for StringUtils.substringBefore(String str, int separator) doesn't mention that the separator is an int. +Add ReflectionDiffBuilder.setExcludeFieldNames(...) and DiffExclude annotation to support field exclusion from diff. Review Comment: Don't edit this file, it will usually clash depending on parallel changes. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-764) IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?focusedWorklogId=752419=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752419
]
ASF GitHub Bot logged work on IO-764:
-
Author: ASF GitHub Bot
Created on: 04/Apr/22 18:04
Start Date: 04/Apr/22 18:04
Worklog Time Spent: 10m
Work Description: michael-o commented on code in PR #343:
URL: https://github.com/apache/commons-io/pull/343#discussion_r842008401
##
src/test/java/org/apache/commons/io/IOUtilsTest.java:
##
@@ -1643,5 +1644,19 @@ public void testToString_URL_CharsetName() throws
Exception {
public void testToString_URL_CharsetNameNull() throws Exception {
testToString_URL(null);
}
+
+@Test
+public void testBigString() throws IOException {
+ String foo = StringUtils.repeat("\uD83D", (Integer.MAX_VALUE)/2-1);
Review Comment:
No shared CI will provide you these resources.
Issue Time Tracking
---
Worklog Id: (was: 752419)
Time Spent: 50m (was: 40m)
> IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while
> writing big strings
>
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-io] michael-o commented on a diff in pull request #343: IO-764 Fix big string writing by writing with ByteBuffer instead calling getBytes directly
michael-o commented on code in PR #343:
URL: https://github.com/apache/commons-io/pull/343#discussion_r842008401
##
src/test/java/org/apache/commons/io/IOUtilsTest.java:
##
@@ -1643,5 +1644,19 @@ public void testToString_URL_CharsetName() throws
Exception {
public void testToString_URL_CharsetNameNull() throws Exception {
testToString_URL(null);
}
+
+@Test
+public void testBigString() throws IOException {
+ String foo = StringUtils.repeat("\uD83D", (Integer.MAX_VALUE)/2-1);
Review Comment:
No shared CI will provide you these resources.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (COLLECTIONS-807) Upgrade org.junit.Test to org.junit.jupiter.api.Test
[
https://issues.apache.org/jira/browse/COLLECTIONS-807?focusedWorklogId=752371=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752371
]
ASF GitHub Bot logged work on COLLECTIONS-807:
--
Author: ASF GitHub Bot
Created on: 04/Apr/22 16:55
Start Date: 04/Apr/22 16:55
Worklog Time Spent: 10m
Work Description: garydgregory commented on PR #295:
URL:
https://github.com/apache/commons-collections/pull/295#issuecomment-1087790470
We are all volunteers here.
Issue Time Tracking
---
Worklog Id: (was: 752371)
Time Spent: 1h (was: 50m)
> Upgrade org.junit.Test to org.junit.jupiter.api.Test
>
>
> Key: COLLECTIONS-807
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-807
> Project: Commons Collections
> Issue Type: Sub-task
>Reporter: John Patrick
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Covers '17' usages of legacy usage of;
> {code:java}
> import org.junit.Test;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-collections] garydgregory commented on pull request #295: COLLECTIONS-807: Upgraded org.junit.Test to org.junit.jupiter.api.Test
garydgregory commented on PR #295: URL: https://github.com/apache/commons-collections/pull/295#issuecomment-1087790470 We are all volunteers here. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] garydgregory commented on a diff in pull request #256: COMPRESS-614: Use FileTime in SevenZArchiveEntry
garydgregory commented on code in PR #256:
URL: https://github.com/apache/commons-compress/pull/256#discussion_r841950804
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -244,6 +247,36 @@ public Date getCreateJavaTime() {
return zipToDate(createTime);
}
+/**
+ * Gets the modify time as as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return modify time as a {@link FileTime} or null.
+ */
+public FileTime getModifyFileTime() {
+return zipToFileTime(modifyTime);
+}
+
+/**
+ * Gets the access time as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return access time as a {@link FileTime} or null.
+ */
+public FileTime getAccessFileTime() {
+return zipToFileTime(accessTime);
+}
+
+/**
+ * Gets the create time as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return create time as a {@link FileTime} or null.
+ */
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -304,6 +337,27 @@ public void setCreateTime(final ZipEightByteInteger t) {
*/
public void setCreateJavaTime(final Date d) { setCreateTime(dateToZip(d));
}
+/**
+ * Sets the modify time.
+ *
+ * @param time modify time as a {@link FileTime}
+ */
+public void setModifyFileTime(final FileTime time) {
setModifyTime(fileTimeToZip(time)); }
+
+/**
+ * Sets the access time.
+ *
+ * @param time access time as a {@link FileTime}
+ */
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -244,6 +247,36 @@ public Date getCreateJavaTime() {
return zipToDate(createTime);
}
+/**
+ * Gets the modify time as as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return modify time as a {@link FileTime} or null.
+ */
+public FileTime getModifyFileTime() {
+return zipToFileTime(modifyTime);
+}
+
+/**
+ * Gets the access time as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return access time as a {@link FileTime} or null.
+ */
+public FileTime getAccessFileTime() {
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -244,6 +247,36 @@ public Date getCreateJavaTime() {
return zipToDate(createTime);
}
+/**
+ * Gets the modify time as as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return modify time as a {@link FileTime} or null.
+ */
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -304,6 +337,27 @@ public void setCreateTime(final ZipEightByteInteger t) {
*/
public void setCreateJavaTime(final Date d) { setCreateTime(dateToZip(d));
}
+/**
+ * Sets the modify time.
+ *
+ * @param time modify time as a {@link FileTime}
+ */
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -304,6 +337,27 @@ public void setCreateTime(final ZipEightByteInteger t) {
*/
public void setCreateJavaTime(final Date d) { setCreateTime(dateToZip(d));
}
+/**
+ * Sets the modify time.
+ *
+ * @param time modify time as a {@link FileTime}
+ */
+public void setModifyFileTime(final FileTime time) {
setModifyTime(fileTimeToZip(time)); }
+
+/**
+ * Sets the access time.
+ *
+ * @param time access time as a {@link FileTime}
+ */
+public void setAccessFileTime(final FileTime time) {
setAccessTime(fileTimeToZip(time)); }
+
+/**
+ * Sets the create time.
+ *
+ * @param time create time as a {@link FileTime}
+ */
+public void setCreateFileTime(final FileTime time) {
setCreateTime(fileTimeToZip(time)); }
Review Comment:
And since tag. Fix formatting.
##
src/test/java/org/apache/commons/compress/utils/TimeUtilsTest.java:
##
@@ -0,0 +1,129 @@
+/*
+ * 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
[jira] [Work logged] (COMPRESS-614) Use FileTime for time fields in SevenZipArchiveEntry
[
https://issues.apache.org/jira/browse/COMPRESS-614?focusedWorklogId=752370=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752370
]
ASF GitHub Bot logged work on COMPRESS-614:
---
Author: ASF GitHub Bot
Created on: 04/Apr/22 16:53
Start Date: 04/Apr/22 16:53
Worklog Time Spent: 10m
Work Description: garydgregory commented on code in PR #256:
URL: https://github.com/apache/commons-compress/pull/256#discussion_r841950804
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -244,6 +247,36 @@ public Date getCreateJavaTime() {
return zipToDate(createTime);
}
+/**
+ * Gets the modify time as as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return modify time as a {@link FileTime} or null.
+ */
+public FileTime getModifyFileTime() {
+return zipToFileTime(modifyTime);
+}
+
+/**
+ * Gets the access time as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return access time as a {@link FileTime} or null.
+ */
+public FileTime getAccessFileTime() {
+return zipToFileTime(accessTime);
+}
+
+/**
+ * Gets the create time as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return create time as a {@link FileTime} or null.
+ */
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -304,6 +337,27 @@ public void setCreateTime(final ZipEightByteInteger t) {
*/
public void setCreateJavaTime(final Date d) { setCreateTime(dateToZip(d));
}
+/**
+ * Sets the modify time.
+ *
+ * @param time modify time as a {@link FileTime}
+ */
+public void setModifyFileTime(final FileTime time) {
setModifyTime(fileTimeToZip(time)); }
+
+/**
+ * Sets the access time.
+ *
+ * @param time access time as a {@link FileTime}
+ */
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -244,6 +247,36 @@ public Date getCreateJavaTime() {
return zipToDate(createTime);
}
+/**
+ * Gets the modify time as as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return modify time as a {@link FileTime} or null.
+ */
+public FileTime getModifyFileTime() {
+return zipToFileTime(modifyTime);
+}
+
+/**
+ * Gets the access time as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return access time as a {@link FileTime} or null.
+ */
+public FileTime getAccessFileTime() {
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -244,6 +247,36 @@ public Date getCreateJavaTime() {
return zipToDate(createTime);
}
+/**
+ * Gets the modify time as as a {@link FileTime}
+ * of this zip entry, or null if no such timestamp exists in the zip entry.
+ *
+ * @return modify time as a {@link FileTime} or null.
+ */
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -304,6 +337,27 @@ public void setCreateTime(final ZipEightByteInteger t) {
*/
public void setCreateJavaTime(final Date d) { setCreateTime(dateToZip(d));
}
+/**
+ * Sets the modify time.
+ *
+ * @param time modify time as a {@link FileTime}
+ */
Review Comment:
And since tag.
##
src/main/java/org/apache/commons/compress/archivers/zip/X000A_NTFS.java:
##
@@ -304,6 +337,27 @@ public void setCreateTime(final ZipEightByteInteger t) {
*/
public void setCreateJavaTime(final Date d) { setCreateTime(dateToZip(d));
}
+/**
+ * Sets the modify time.
+ *
+ * @param time modify time as a {@link FileTime}
+ */
+public void setModifyFileTime(final FileTime time) {
setModifyTime(fileTimeToZip(time)); }
+
+/**
+ * Sets the access time.
+ *
+ * @param time access time as a {@link FileTime}
+ */
+public void setAccessFileTime(final FileTime time) {
setAccessTime(fileTimeToZip(time)); }
+
+/**
+ * Sets the create time.
+ *
+ * @param time create time as a {@link FileTime}
+ */
+public void setCreateFileTime(final FileTime time) {
setCreateTime(fileTimeToZip(time)); }
Review Comment:
And since tag. Fix formatting.
##
src/test/java/org/apache/commons/compress/utils/TimeUtilsTest.java:
##
@@ -0,0 +1,129 @@
+/*
[jira] [Work logged] (COLLECTIONS-807) Upgrade org.junit.Test to org.junit.jupiter.api.Test
[
https://issues.apache.org/jira/browse/COLLECTIONS-807?focusedWorklogId=752358=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752358
]
ASF GitHub Bot logged work on COLLECTIONS-807:
--
Author: ASF GitHub Bot
Created on: 04/Apr/22 16:32
Start Date: 04/Apr/22 16:32
Worklog Time Spent: 10m
Work Description: pradeesh-kumar commented on PR #295:
URL:
https://github.com/apache/commons-collections/pull/295#issuecomment-1087769953
How's the review and merge process for the PRs? Is there any specific amount
of time taking to review and merge? Is it based on some priority? I'm curious
to know since this PR was raised some days back, didn't see any
reviews/comments/updates yet.
Issue Time Tracking
---
Worklog Id: (was: 752358)
Time Spent: 50m (was: 40m)
> Upgrade org.junit.Test to org.junit.jupiter.api.Test
>
>
> Key: COLLECTIONS-807
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-807
> Project: Commons Collections
> Issue Type: Sub-task
>Reporter: John Patrick
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Covers '17' usages of legacy usage of;
> {code:java}
> import org.junit.Test;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-collections] pradeesh-kumar commented on pull request #295: COLLECTIONS-807: Upgraded org.junit.Test to org.junit.jupiter.api.Test
pradeesh-kumar commented on PR #295: URL: https://github.com/apache/commons-collections/pull/295#issuecomment-1087769953 How's the review and merge process for the PRs? Is there any specific amount of time taking to review and merge? Is it based on some priority? I'm curious to know since this PR was raised some days back, didn't see any reviews/comments/updates yet. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] andrebrait commented on pull request #256: COMPRESS-614: Use FileTime in SevenZArchiveEntry
andrebrait commented on PR #256: URL: https://github.com/apache/commons-compress/pull/256#issuecomment-1087699134 @garydgregory waiting for this to be merged so I can send the changes for COMPRESS-613 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-614) Use FileTime for time fields in SevenZipArchiveEntry
[ https://issues.apache.org/jira/browse/COMPRESS-614?focusedWorklogId=752320=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752320 ] ASF GitHub Bot logged work on COMPRESS-614: --- Author: ASF GitHub Bot Created on: 04/Apr/22 15:25 Start Date: 04/Apr/22 15:25 Worklog Time Spent: 10m Work Description: andrebrait commented on PR #256: URL: https://github.com/apache/commons-compress/pull/256#issuecomment-1087699134 @garydgregory waiting for this to be merged so I can send the changes for COMPRESS-613 Issue Time Tracking --- Worklog Id: (was: 752320) Time Spent: 1h 40m (was: 1.5h) > Use FileTime for time fields in SevenZipArchiveEntry > > > Key: COMPRESS-614 > URL: https://issues.apache.org/jira/browse/COMPRESS-614 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: 7zip > Time Spent: 1h 40m > Remaining Estimate: 0h > > Instead of java.util.Date, which caps precision in milliseconds, let's move > on to using FileTime. > We can keep backwards compatibility through the getters and setters for > modification, access and creation dates. > If you're ok with it, I'll send a PR for this. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516875#comment-17516875
]
Gilles Sadowski edited comment on GEOMETRY-146 at 4/4/22 3:19 PM:
--
{quote}[...] near/far qualification is important enough to warrant inclusion in
the top-level public API.
{quote}
>From this assumption, I'd suggest that the class name reflects its importance,
>similarly to the "Navigable" qualifier in the [JDK
>{{NavigableMap}}|https://docs.oracle.com/javase/8/docs/api/java/util/NavigableMap.html].
{quote}
{code:java}
PointMap.EntrySetSelector selector =
map.withinDistance(resolution);
// ...
PointMap.EntrySet subSet = selector.apply(v);
{code}
Also, the subset selection here seems to be split into two parts: the first to
specify the distance and the second to specify the reference point. I don't see
a reason to separate these.
{quote}
In this case, there may be no reason; but we could imagine another selector
where some part of the computation is performed at instantiation and should not
be repeated for each point.
When the use-case does not need the separation, the call is a one-liner
{code:java}
PointMap.EntrySet subSet =
map.withinDistance(resolution).apply(v);
{code}
Could selectors be defined as
{code:java}
class PointMap {
public interface Selector extends Function, P> {};
}
{code}
?
Can the "sub-map" be a "view" of the same data-structure?
Given a point "p" of type {{P,}} are the 2 iterators (over all points in the
{{PointMap}} instance):
* in increasing distance from "p"
* in decreasing distance
"naturally" (efficiently) defined?
was (Author: erans):
{quote}[...] near/far qualification is important enough to warrant inclusion in
the top-level public API.
{quote}
>From this assumption, I'd suggest that the class name reflects its importance,
>similarly to the "Navigable" qualifier in the [JDK
>{{NavigableMap}}|https://docs.oracle.com/javase/8/docs/api/java/util/NavigableMap.html].
{quote}
{code:java}
PointMap.EntrySetSelector selector =
map.withinDistance(resolution);
// ...
PointMap.EntrySet subSet = selector.apply(v);
{code}
Also, the subset selection here seems to be split into two parts: the first to
specify the distance and the second to specify the reference point. I don't see
a reason to separate these.
{quote}
In this case, there may be no reason; but we could imagine another selector
where some part of the computation is performed at instantiation and should not
be repeated for each point.
When the use-case does not need the separation, the call is a one-liner
{code:java}
PointMap.EntrySet subSet =
map.withinDistance(resolution).apply(v);
{code}
{quote}
Computing distance between points is one of the few things that all spaces and
dimensions provide [...]
{quote}
Does it allow defining selectors as
{code}
class PointMap {
public interface Selector extends Function, P> {};
}
{code}
?
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516875#comment-17516875
]
Gilles Sadowski commented on GEOMETRY-146:
--
{quote}[...] near/far qualification is important enough to warrant inclusion in
the top-level public API.
{quote}
>From this assumption, I'd suggest that the class name reflects its importance,
>similarly to the "Navigable" qualifier in the [JDK
>{{NavigableMap}}|https://docs.oracle.com/javase/8/docs/api/java/util/NavigableMap.html].
{quote}
{code:java}
PointMap.EntrySetSelector selector =
map.withinDistance(resolution);
// ...
PointMap.EntrySet subSet = selector.apply(v);
{code}
Also, the subset selection here seems to be split into two parts: the first to
specify the distance and the second to specify the reference point. I don't see
a reason to separate these.
{quote}
In this case, there may be no reason; but we could imagine another selector
where some part of the computation is performed at instantiation and should not
be repeated for each point.
When the use-case does not need the separation, the call is a one-liner
{code:java}
PointMap.EntrySet subSet =
map.withinDistance(resolution).apply(v);
{code}
{quote}
Computing distance between points is one of the few things that all spaces and
dimensions provide [...]
{quote}
Does it allow defining selectors as
{code}
class PointMap {
public interface Selector extends Function, P> {};
}
{code}
?
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JCS-229) LateralTCPListener class uses always StandardSerializer
[ https://issues.apache.org/jira/browse/JCS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dorota Oeknigk-Urbanska updated JCS-229: Description: Version jcs-3.1 introduced an option to use EncryptingSerializer instead of StandardSerializer. However when EncryptingSerializer is configured for LTCP by : jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer synchronization does not work. LateralTCPSender supports custom Serializer (by constructor which allowed LateralTCPService to pass Serializer as parameter)- and it's properly sending encripted messages. LateralTCPListener does not support custom Serializer and uses always StandardSerializer - which in this case when received message is encripted fails. Solution attached in patch.diff file. was: Version jcs-3.1 introduced an option to use EncryptingSerializer instead of StandardSerializer. However when EncryptingSerializer is configured for LTCP by : jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer synchronization does not work. LateralTCPSender supports custom Serializer (by constructor which allowed LateralTCPService to pass Serializer as parameter)- and it's properly sending encripted messages. LateralTCPListener does not support custom Serializer and uses always StandardSerializer - which in this case when received message is encripted fails. > LateralTCPListener class uses always StandardSerializer > --- > > Key: JCS-229 > URL: https://issues.apache.org/jira/browse/JCS-229 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Priority: Major > Attachments: patch.diff > > Original Estimate: 4h > Remaining Estimate: 4h > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > synchronization does not work. > LateralTCPSender supports custom Serializer (by constructor which allowed > LateralTCPService to pass Serializer as parameter)- and it's properly sending > encripted messages. LateralTCPListener does not support custom Serializer and > uses always StandardSerializer - which in this case when received message is > encripted fails. > > > Solution attached in patch.diff file. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JCS-230) UDPDiscoveryReceiver with EncryptingSerializer fails
[ https://issues.apache.org/jira/browse/JCS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dorota Oeknigk-Urbanska updated JCS-230: Description: Version jcs-3.1 introduced an option to use EncryptingSerializer instead of StandardSerializer. However when EncryptingSerializer is configured for LTCP by : jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer UDPDiscoveryReceiver throws an error when trying to serialize received message ( error bellow). Root cause of this error: calling deSerialize method in line 265 : serializer.deSerialize(byteBuffer.array(), null); byteBuffer.array() - returns byte[] which size is the full capacity of ByteBuffer not the size of recived message. Apr 04, 2022 2:16:19 PM org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver SEVERE: Error receiving multicast packet java.io.IOException: Error while decrypting at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:209) at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.deSerialize(EncryptingSerializer.java:247) at org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver.run(UDPDiscoveryReceiver.java:265) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 16 when decrypting with padded cipher at java.base/com.sun.crypto.provider.CipherCore.prepareInputBuffer(CipherCore.java:1005) at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:848) at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:203) ... 3 more Solution attached in patch.diff file. was: Version jcs-3.1 introduced an option to use EncryptingSerializer instead of StandardSerializer. However when EncryptingSerializer is configured for LTCP by : jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer UDPDiscoveryReceiver throws an error when trying to serialize received message ( error bellow). Root cause of this error: calling deSerialize method in line 265 : serializer.deSerialize(byteBuffer.array(), null); byteBuffer.array() - returns byte[] which size is the full capacity of ByteBuffer not the size of recived message. Apr 04, 2022 2:16:19 PM org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver SEVERE: Error receiving multicast packet java.io.IOException: Error while decrypting at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:209) at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.deSerialize(EncryptingSerializer.java:247) at org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver.run(UDPDiscoveryReceiver.java:265) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 16 when decrypting with padded cipher at java.base/com.sun.crypto.provider.CipherCore.prepareInputBuffer(CipherCore.java:1005) at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:848) at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:203) ... 3 more > UDPDiscoveryReceiver with EncryptingSerializer fails > > > Key: JCS-230 > URL: https://issues.apache.org/jira/browse/JCS-230 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Priority: Major > Attachments: patch.diff > > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > UDPDiscoveryReceiver throws an error when trying to serialize received > message ( error bellow). > > Root cause of this error: > calling deSerialize method in line 265 : > serializer.deSerialize(byteBuffer.array(), null); > byteBuffer.array() - returns byte[] which size is the full capacity of > ByteBuffer not the size of recived message. > > > Apr 04, 2022 2:16:19 PM > org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver > SEVERE: Error receiving multicast packet > java.io.IOException: Error
[jira] [Commented] (IO-764) IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516804#comment-17516804
]
Gary D. Gregory commented on IO-764:
Hello [~DaGeRe1989]
Thank you for your PR, but it breaks existing tests, please see my comments in
the PR.
> IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while
> writing big strings
>
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (IO-764) IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?focusedWorklogId=752229=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752229
]
ASF GitHub Bot logged work on IO-764:
-
Author: ASF GitHub Bot
Created on: 04/Apr/22 13:01
Start Date: 04/Apr/22 13:01
Worklog Time Spent: 10m
Work Description: garydgregory commented on code in PR #343:
URL: https://github.com/apache/commons-io/pull/343#discussion_r841652865
##
src/test/java/org/apache/commons/io/IOUtilsTest.java:
##
@@ -1643,5 +1644,19 @@ public void testToString_URL_CharsetName() throws
Exception {
public void testToString_URL_CharsetNameNull() throws Exception {
testToString_URL(null);
}
+
+@Test
+public void testBigString() throws IOException {
+ String foo = StringUtils.repeat("\uD83D", (Integer.MAX_VALUE)/2-1);
+
+ OutputStream dummyStream = new OutputStream() {
Review Comment:
- Use final where you can.
- Use NullOutputStream instead of custom code
- Use CountingOutputStream to at least validate that we wrote the proper
amount of data.
- Try to use mocking to insure the right thing happened
- Even try to use mocking (Mockito and/or Powermock) to see if you can mock
the string test fixture.
##
src/main/java/org/apache/commons/io/IOUtils.java:
##
@@ -3362,7 +3364,12 @@ public static void write(final String data, final
OutputStream output)
*/
public static void write(final String data, final OutputStream output,
final Charset charset) throws IOException {
if (data != null) {
-output.write(data.getBytes(Charsets.toCharset(charset)));
+Charset usableCharset = Charsets.toCharset(charset);
Review Comment:
- Needs comments as to why the implementation changed and is what it is
since we do not want someone else to come and "simplify" the code. In-line
locals.
##
src/main/java/org/apache/commons/io/IOUtils.java:
##
@@ -3362,7 +3364,12 @@ public static void write(final String data, final
OutputStream output)
*/
public static void write(final String data, final OutputStream output,
final Charset charset) throws IOException {
if (data != null) {
-output.write(data.getBytes(Charsets.toCharset(charset)));
+Charset usableCharset = Charsets.toCharset(charset);
+ByteBuffer bytebuffer = usableCharset.encode(data);
+
+try (WritableByteChannel channel = Channels.newChannel(output)){
+ channel.write(bytebuffer);
+}
Review Comment:
This incorrectly closes the output stream. Run a full build or just
`IOUtilsWriteTest`:
```
IOUtilsWriteTest
org.apache.commons.io.IOUtilsWriteTest
testWrite_charSequenceToOutputStream_nullEncoding(org.apache.commons.io.IOUtilsWriteTest)
org.opentest4j.AssertionFailedError:
ThrowOnFlushAndCloseOutputStream.close() called.
at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:134)
at
org.apache.commons.io.test.ThrowOnFlushAndCloseOutputStream.close(ThrowOnFlushAndCloseOutputStream.java:50)
at
java.nio.channels.Channels$WritableByteChannelImpl.implCloseChannel(Channels.java:469)
at
java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:115)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3372)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3285)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3311)
at
org.apache.commons.io.IOUtilsWriteTest.testWrite_charSequenceToOutputStream_nullEncoding(IOUtilsWriteTest.java:348)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
[GitHub] [commons-io] garydgregory commented on a diff in pull request #343: IO-764 Fix big string writing by writing with ByteBuffer instead calling getBytes directly
garydgregory commented on code in PR #343:
URL: https://github.com/apache/commons-io/pull/343#discussion_r841652865
##
src/test/java/org/apache/commons/io/IOUtilsTest.java:
##
@@ -1643,5 +1644,19 @@ public void testToString_URL_CharsetName() throws
Exception {
public void testToString_URL_CharsetNameNull() throws Exception {
testToString_URL(null);
}
+
+@Test
+public void testBigString() throws IOException {
+ String foo = StringUtils.repeat("\uD83D", (Integer.MAX_VALUE)/2-1);
+
+ OutputStream dummyStream = new OutputStream() {
Review Comment:
- Use final where you can.
- Use NullOutputStream instead of custom code
- Use CountingOutputStream to at least validate that we wrote the proper
amount of data.
- Try to use mocking to insure the right thing happened
- Even try to use mocking (Mockito and/or Powermock) to see if you can mock
the string test fixture.
##
src/main/java/org/apache/commons/io/IOUtils.java:
##
@@ -3362,7 +3364,12 @@ public static void write(final String data, final
OutputStream output)
*/
public static void write(final String data, final OutputStream output,
final Charset charset) throws IOException {
if (data != null) {
-output.write(data.getBytes(Charsets.toCharset(charset)));
+Charset usableCharset = Charsets.toCharset(charset);
Review Comment:
- Needs comments as to why the implementation changed and is what it is
since we do not want someone else to come and "simplify" the code. In-line
locals.
##
src/main/java/org/apache/commons/io/IOUtils.java:
##
@@ -3362,7 +3364,12 @@ public static void write(final String data, final
OutputStream output)
*/
public static void write(final String data, final OutputStream output,
final Charset charset) throws IOException {
if (data != null) {
-output.write(data.getBytes(Charsets.toCharset(charset)));
+Charset usableCharset = Charsets.toCharset(charset);
+ByteBuffer bytebuffer = usableCharset.encode(data);
+
+try (WritableByteChannel channel = Channels.newChannel(output)){
+ channel.write(bytebuffer);
+}
Review Comment:
This incorrectly closes the output stream. Run a full build or just
`IOUtilsWriteTest`:
```
IOUtilsWriteTest
org.apache.commons.io.IOUtilsWriteTest
testWrite_charSequenceToOutputStream_nullEncoding(org.apache.commons.io.IOUtilsWriteTest)
org.opentest4j.AssertionFailedError:
ThrowOnFlushAndCloseOutputStream.close() called.
at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:134)
at
org.apache.commons.io.test.ThrowOnFlushAndCloseOutputStream.close(ThrowOnFlushAndCloseOutputStream.java:50)
at
java.nio.channels.Channels$WritableByteChannelImpl.implCloseChannel(Channels.java:469)
at
java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:115)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3372)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3285)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3311)
at
org.apache.commons.io.IOUtilsWriteTest.testWrite_charSequenceToOutputStream_nullEncoding(IOUtilsWriteTest.java:348)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
[jira] [Created] (JCS-230) UDPDiscoveryReceiver with EncryptingSerializer fails
Dorota Oeknigk-Urbanska created JCS-230: --- Summary: UDPDiscoveryReceiver with EncryptingSerializer fails Key: JCS-230 URL: https://issues.apache.org/jira/browse/JCS-230 Project: Commons JCS Issue Type: Bug Components: TCP Lateral Cache Affects Versions: jcs-3.1 Reporter: Dorota Oeknigk-Urbanska Attachments: patch.diff Version jcs-3.1 introduced an option to use EncryptingSerializer instead of StandardSerializer. However when EncryptingSerializer is configured for LTCP by : jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer UDPDiscoveryReceiver throws an error when trying to serialize received message ( error bellow). Root cause of this error: calling deSerialize method in line 265 : serializer.deSerialize(byteBuffer.array(), null); byteBuffer.array() - returns byte[] which size is the full capacity of ByteBuffer not the size of recived message. Apr 04, 2022 2:16:19 PM org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver SEVERE: Error receiving multicast packet java.io.IOException: Error while decrypting at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:209) at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.deSerialize(EncryptingSerializer.java:247) at org.apache.commons.jcs3.utils.discovery.UDPDiscoveryReceiver.run(UDPDiscoveryReceiver.java:265) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 16 when decrypting with padded cipher at java.base/com.sun.crypto.provider.CipherCore.prepareInputBuffer(CipherCore.java:1005) at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:848) at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) at org.apache.commons.jcs3.utils.serialization.EncryptingSerializer.decrypt(EncryptingSerializer.java:203) ... 3 more -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IO-764) IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516785#comment-17516785
]
David Georg Reichelt commented on IO-764:
-
Yes, it works if you start it with -Xmx8g (and I testet with OpenJDK 11 and 8).
The question is whether this would be suitable for regular testing in CI (than,
surefire needs -Xmx8g), or whether I should disable the test by default.
> IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while
> writing big strings
>
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IO-764) IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-764:
---
Summary: IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException
while writing big strings (was: IOUtils.write() throws
NegativeArraySizeException while writing big strings)
> IOUtils.write() throws OutOfMemoryError/NegativeArraySizeException while
> writing big strings
>
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IO-764) IOUtils.write() throws NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516776#comment-17516776
]
Gary D. Gregory commented on IO-764:
FTR, I get in my local test:
{noformat}
java.lang.OutOfMemoryError: Java heap space
at java.lang.StringCoding.encode(StringCoding.java:350)
at java.lang.String.getBytes(String.java:941)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3367)
at org.apache.commons.io.IOUtilsTest.testBigString(IOUtilsTest.java:1659)
{noformat}
> IOUtils.write() throws NegativeArraySizeException while writing big strings
> ---
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JCS-229) LateralTCPListener class uses always StandardSerializer
[ https://issues.apache.org/jira/browse/JCS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dorota Oeknigk-Urbanska updated JCS-229: Attachment: patch.diff > LateralTCPListener class uses always StandardSerializer > --- > > Key: JCS-229 > URL: https://issues.apache.org/jira/browse/JCS-229 > Project: Commons JCS > Issue Type: Bug > Components: TCP Lateral Cache >Affects Versions: jcs-3.1 >Reporter: Dorota Oeknigk-Urbanska >Priority: Major > Attachments: patch.diff > > Original Estimate: 4h > Remaining Estimate: 4h > > Version jcs-3.1 introduced an option to use EncryptingSerializer instead of > StandardSerializer. > However when EncryptingSerializer is configured for LTCP by : > jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer > synchronization does not work. > LateralTCPSender supports custom Serializer (by constructor which allowed > LateralTCPService to pass Serializer as parameter)- and it's properly sending > encripted messages. LateralTCPListener does not support custom Serializer and > uses always StandardSerializer - which in this case when received message is > encripted fails. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (JCS-229) LateralTCPListener class uses always StandardSerializer
Dorota Oeknigk-Urbanska created JCS-229: --- Summary: LateralTCPListener class uses always StandardSerializer Key: JCS-229 URL: https://issues.apache.org/jira/browse/JCS-229 Project: Commons JCS Issue Type: Bug Components: TCP Lateral Cache Affects Versions: jcs-3.1 Reporter: Dorota Oeknigk-Urbanska Version jcs-3.1 introduced an option to use EncryptingSerializer instead of StandardSerializer. However when EncryptingSerializer is configured for LTCP by : jcs.auxiliary.LTCP.serializer=org.apache.commons.jcs3.utils.serialization.EncryptingSerializer synchronization does not work. LateralTCPSender supports custom Serializer (by constructor which allowed LateralTCPService to pass Serializer as parameter)- and it's properly sending encripted messages. LateralTCPListener does not support custom Serializer and uses always StandardSerializer - which in this case when received message is encripted fails. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (IO-764) IOUtils.write() throws NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?focusedWorklogId=752200=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752200
]
ASF GitHub Bot logged work on IO-764:
-
Author: ASF GitHub Bot
Created on: 04/Apr/22 11:43
Start Date: 04/Apr/22 11:43
Worklog Time Spent: 10m
Work Description: garydgregory commented on PR #343:
URL: https://github.com/apache/commons-io/pull/343#issuecomment-1087452317
https://issues.apache.org/jira/browse/IO-764
Issue Time Tracking
---
Worklog Id: (was: 752200)
Time Spent: 0.5h (was: 20m)
> IOUtils.write() throws NegativeArraySizeException while writing big strings
> ---
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IO-764) IOUtils.write() throws NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516759#comment-17516759
]
Gary D. Gregory commented on IO-764:
https://github.com/apache/commons-io/pull/343
> IOUtils.write() throws NegativeArraySizeException while writing big strings
> ---
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-io] garydgregory commented on pull request #343: IO-764 Fix big string writing by writing with ByteBuffer instead calling getBytes directly
garydgregory commented on PR #343: URL: https://github.com/apache/commons-io/pull/343#issuecomment-1087452317 https://issues.apache.org/jira/browse/IO-764 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (IO-764) NegativeArraySizeException thrown while writing big strings using IOUtils.write()
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-764:
---
Summary: NegativeArraySizeException thrown while writing big strings using
IOUtils.write() (was: NegativeArraySizeException thrown while writing big
atrings Using IOUtils)
> NegativeArraySizeException thrown while writing big strings using
> IOUtils.write()
> -
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IO-764) IOUtils.write() throws NegativeArraySizeException while writing big strings
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-764:
---
Summary: IOUtils.write() throws NegativeArraySizeException while writing
big strings (was: NegativeArraySizeException thrown while writing big strings
using IOUtils.write())
> IOUtils.write() throws NegativeArraySizeException while writing big strings
> ---
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IO-764) NegativeArraySizeException thrown while writing big atrings Using IOUtils
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-764:
---
Summary: NegativeArraySizeException thrown while writing big atrings Using
IOUtils (was: Unable to Write Big Strings Using IOUtils)
> NegativeArraySizeException thrown while writing big atrings Using IOUtils
> -
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IO-764) Unable to Write Big Strings Using IOUtils
[
https://issues.apache.org/jira/browse/IO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-764:
---
Assignee: Gary D. Gregory
> Unable to Write Big Strings Using IOUtils
> -
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Assignee: Gary D. Gregory
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (IO-764) Unable to Write Big Strings Using IOUtils
[
https://issues.apache.org/jira/browse/IO-764?focusedWorklogId=752181=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752181
]
ASF GitHub Bot logged work on IO-764:
-
Author: ASF GitHub Bot
Created on: 04/Apr/22 10:24
Start Date: 04/Apr/22 10:24
Worklog Time Spent: 10m
Work Description: DaGeRe commented on PR #343:
URL: https://github.com/apache/commons-io/pull/343#issuecomment-1087378794
Unfortunately, this does not work on GH Actions since the RAM is too small.
Should I increase the RAM for the test or disable the test?
Issue Time Tracking
---
Worklog Id: (was: 752181)
Time Spent: 20m (was: 10m)
> Unable to Write Big Strings Using IOUtils
> -
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-io] DaGeRe commented on pull request #343: IO-764 Fix big string writing by writing with ByteBuffer instead calling getBytes directly
DaGeRe commented on PR #343: URL: https://github.com/apache/commons-io/pull/343#issuecomment-1087378794 Unfortunately, this does not work on GH Actions since the RAM is too small. Should I increase the RAM for the test or disable the 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-764) Unable to Write Big Strings Using IOUtils
[
https://issues.apache.org/jira/browse/IO-764?focusedWorklogId=752177=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752177
]
ASF GitHub Bot logged work on IO-764:
-
Author: ASF GitHub Bot
Created on: 04/Apr/22 10:15
Start Date: 04/Apr/22 10:15
Worklog Time Spent: 10m
Work Description: DaGeRe opened a new pull request, #343:
URL: https://github.com/apache/commons-io/pull/343
If Strings with a certain size are written to a stream, this fails with an
exception on OpenJDK 11.
```
java.lang.NegativeArraySizeException: -1283060862
at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
at java.base/java.lang.String.getBytes(String.java:964)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524)
```
This PR fixes the problem by using a `ByteBuffer` instead `getBytes`.
Unfortunately, this increases test time significantly. One workaround would
be to disable the test and only enable it if needed - but testing whether big
Strings can be written is not possible without handling such a big string.
Issue Time Tracking
---
Worklog Id: (was: 752177)
Remaining Estimate: 0h
Time Spent: 10m
> Unable to Write Big Strings Using IOUtils
> -
>
> Key: IO-764
> URL: https://issues.apache.org/jira/browse/IO-764
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: David Georg Reichelt
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, if I try to write a sufficiently big to a stream, IOUtils.write
> fails:
> {code:java}
> java.lang.NegativeArraySizeException: -1283060862
> at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
> at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
> at java.base/java.lang.String.getBytes(String.java:964)
> at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
> at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
> at
> org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
> The reason for this is that getBytes does not support Strings with this size.
> This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-io] DaGeRe opened a new pull request, #343: IO-764 Fix big string writing by writing with ByteBuffer instead calling getBytes directly
DaGeRe opened a new pull request, #343: URL: https://github.com/apache/commons-io/pull/343 If Strings with a certain size are written to a stream, this fails with an exception on OpenJDK 11. ``` java.lang.NegativeArraySizeException: -1283060862 at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904) at java.base/java.lang.StringCoding.encode(StringCoding.java:449) at java.base/java.lang.String.getBytes(String.java:964) at org.apache.commons.io.IOUtils.write(IOUtils.java:3251) at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541) at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524) ``` This PR fixes the problem by using a `ByteBuffer` instead `getBytes`. Unfortunately, this increases test time significantly. One workaround would be to disable the test and only enable it if needed - but testing whether big Strings can be written is not possible without handling such a big string. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (IO-764) Unable to Write Big Strings Using IOUtils
David Georg Reichelt created IO-764:
---
Summary: Unable to Write Big Strings Using IOUtils
Key: IO-764
URL: https://issues.apache.org/jira/browse/IO-764
Project: Commons IO
Issue Type: Bug
Affects Versions: 2.11.0
Reporter: David Georg Reichelt
Currently, if I try to write a sufficiently big to a stream, IOUtils.write
fails:
{code:java}
java.lang.NegativeArraySizeException: -1283060862
at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
at java.base/java.lang.StringCoding.encode(StringCoding.java:449)
at java.base/java.lang.String.getBytes(String.java:964)
at org.apache.commons.io.IOUtils.write(IOUtils.java:3251)
at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3541)
at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:3524){code}
The reason for this is that getBytes does not support Strings with this size.
This should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MATH-1643) Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations.
[ https://issues.apache.org/jira/browse/MATH-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516669#comment-17516669 ] AVIJIT BASAK commented on MATH-1643: Modified the Jira description. Implementation is as per current description. > Implementation of multi-threading in Genetic Algorithm and parallel GA with > multiple populations. > - > > Key: MATH-1643 > URL: https://issues.apache.org/jira/browse/MATH-1643 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Fix For: 4.0 > > > Current implementation of Genetic Algorithm does not use *multi-threading* > during optimization process. A multi-threading approach would be required to > enable usage of multiple cores of user CPU. This would also enable > implementation of *parallel GA* with multiple populations where each > population would converge independently, and the list of converged > populations will be returned to caller. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MATH-1643) Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations.
[ https://issues.apache.org/jira/browse/MATH-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1643: --- Description: Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the list of converged populations will be returned to caller. (was: Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the list of converged population will be returned to caller.) > Implementation of multi-threading in Genetic Algorithm and parallel GA with > multiple populations. > - > > Key: MATH-1643 > URL: https://issues.apache.org/jira/browse/MATH-1643 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Fix For: 4.0 > > > Current implementation of Genetic Algorithm does not use *multi-threading* > during optimization process. A multi-threading approach would be required to > enable usage of multiple cores of user CPU. This would also enable > implementation of *parallel GA* with multiple populations where each > population would converge independently, and the list of converged > populations will be returned to caller. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MATH-1643) Implementation of multi-threading in Genetic Algorithm and parallel GA with multiple populations.
[ https://issues.apache.org/jira/browse/MATH-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AVIJIT BASAK updated MATH-1643: --- Description: Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the list of converged population will be returned to caller. (was: Current implementation of Genetic Algorithm does not use *multi-threading* during optimization process. A multi-threading approach would be required to enable usage of multiple cores of user CPU. This would also enable implementation of *parallel GA* with multiple populations where each population would converge independently, and the best result will be accepted as a solution.) > Implementation of multi-threading in Genetic Algorithm and parallel GA with > multiple populations. > - > > Key: MATH-1643 > URL: https://issues.apache.org/jira/browse/MATH-1643 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.6.1 >Reporter: AVIJIT BASAK >Priority: Major > Fix For: 4.0 > > > Current implementation of Genetic Algorithm does not use *multi-threading* > during optimization process. A multi-threading approach would be required to > enable usage of multiple cores of user CPU. This would also enable > implementation of *parallel GA* with multiple populations where each > population would converge independently, and the list of converged > population will be returned to caller. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (DBCP-585) Connection level JMX queries result in concurrent access to connection objects, causing errors
[
https://issues.apache.org/jira/browse/DBCP-585?focusedWorklogId=752103=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-752103
]
ASF GitHub Bot logged work on DBCP-585:
---
Author: ASF GitHub Bot
Created on: 04/Apr/22 06:56
Start Date: 04/Apr/22 06:56
Worklog Time Spent: 10m
Work Description: kurtcebe commented on PR #179:
URL: https://github.com/apache/commons-dbcp/pull/179#issuecomment-1087183125
CI failed as source file length check reported 6 lines over the limit. I've
amended PR to make the source file shorter.
Issue Time Tracking
---
Worklog Id: (was: 752103)
Remaining Estimate: 0h
Time Spent: 10m
> Connection level JMX queries result in concurrent access to connection
> objects, causing errors
> --
>
> Key: DBCP-585
> URL: https://issues.apache.org/jira/browse/DBCP-585
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Kurtcebe Eroglu
>Priority: Major
> Attachments: 0001-DBCP-585-idea-clarification-1.patch,
> conn_instance_attrs.png, connections_attrs.png, ds_attrs.png, final.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As we expose Connection objects over JMX, they may be accessed by multiple
> threads concurrently;
> a) an application thread that borrows the Connection and uses it business as
> usual,
> b) another thread simultaneously performing a JMX query, which in turn calls
> getters on the same connection object via the MBean interface.
> Also, calls to Connection object getters are mostly delegated to the
> underlying vendor-specific connection provided by the JDBC driver. For
> example, when we make the JMX query to get the "schema" attribute of the JMX
> connection object, this is translated into a
> "java.sql.Connection.getSchema()", and passed to the vendor-specific
> Connection object by DBCP. In the case of Postgres, for example, this is
> further translated to a query "select current_schema()" and sent to the
> server.
> Hence, querying connections over JMX result in concurrent access by multiple
> threads to the underlying Connection provided by the vendors, to the point
> that these two threads may be running queries simultaneously on the same
> connection.
> However, this is not supported by any of the major database vendors. Vendor
> links on Connection objects not being threadsafe:
> - [Postgres|https://jdbc.postgresql.org/documentation/head/thread.html]
> {quote}The PostgreSQL™ JDBC driver is not thread safe. The PostgreSQL server
> is not threaded. Each connection creates a new process on the server; as such
> any concurrent requests to the process would have to be serialized. The
> driver makes no guarantees that methods on connections are synchronized. It
> will be up to the caller to synchronize calls to the driver.
> {quote}
> -
> [Oracle|https://docs.oracle.com/en/database/oracle/oracle-database/19/jjdbc/JDBC-coding-tips.html#GUID-EE479007-D105-4F82-8D51-000CBBD4BC77]
>
> {quote}Oracle strongly discourages sharing a database connection among
> multiple threads. Avoid allowing multiple threads to access a connection
> simultaneously.
> {quote}
> - [Microsoft SQL
> Server|https://www.javadoc.io/doc/com.microsoft.sqlserver/mssql-jdbc/latest/com.microsoft.sqlserver.jdbc/com/microsoft/sqlserver/jdbc/SQLServerConnection.html]
> {quote}SQLServerConnection is not thread safe, however multiple statements
> created from a single connection can be processing simultaneously in
> concurrent threads.
> {quote}
> Another interesting point to note, also to do justice to previous committers
> who have put this feature in place, is that this was not always the case. In
> the following links, you may see the same links to the older versions of the
> same pages. In the past, all vendors indicated that Connection is fully
> thread-safe; [Postgres|https://www.postgresql.org/docs/7.1/jdbc-thread.html],
> [Oracle|https://docs.oracle.com/cd/A97335_02/apps.102/a83724/tips1.htm],
> [MSSQL
> Server|https://www.javadoc.io/doc/com.microsoft.sqlserver/mssql-jdbc/6.1.0.jre7/com/microsoft/sqlserver/jdbc/SQLServerConnection.html].
>
> Hence, it was once safe to expose Connection objects via JMX given the
> thread-safety guarantees for the underlying vendor connection were in place.
> But as Vendors dropped the thread-safety guarantee one by one, it is not safe
> anymore, and may actually cause convoluted errors that pop up intermittently
> due to thread races in the JDBC driver code (see an example in the comments
> section below). Accordingly, exposing Connections via JMX shall be retired
> along with dropped support from most vendors.
> Note: the
[GitHub] [commons-dbcp] kurtcebe commented on pull request #179: DBCP-585 PR for idea clarification
kurtcebe commented on PR #179: URL: https://github.com/apache/commons-dbcp/pull/179#issuecomment-1087183125 CI failed as source file length check reported 6 lines over the limit. I've amended PR to make the source file shorter. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
