[jira] [Commented] (IMAGING-281) Simple Exif XPTitle corrupted.
[
https://issues.apache.org/jira/browse/IMAGING-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287588#comment-17287588
]
Bruno P. Kinoshita commented on IMAGING-281:
Thanks for posting the solution for this issue [~garretwilson] . And for
updating this ticket as well :)
> Simple Exif XPTitle corrupted.
> --
>
> Key: IMAGING-281
> URL: https://issues.apache.org/jira/browse/IMAGING-281
> Project: Commons Imaging
> Issue Type: Bug
>Affects Versions: 1.0-alpha2
>Reporter: Garret Wilson
>Priority: Blocker
> Attachments: gate-turret-exif-bad-title.jpg
>
>
> I have a small input JPEG image containing _no metadata sections whatsoever_.
> I use Apache Commons Imaging 1.0-alpha2 to add two simple Exif {{IFD0}}
> properties using
> [{{ExifRewriter().updateExifMetadataLossy()}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.html#updateExifMetadataLossy-org.apache.commons.imaging.common.bytesource.ByteSource-java.io.OutputStream-org.apache.commons.imaging.formats.tiff.write.TiffOutputSet-].
> * {{XPTitle}} ({{0x9C9B}}): "Gate and Turret"
> * {{Copyright}} ({{33432}}, {{0x8298}}): "Copyright © 2009 Garret Wilson"
> Here is a simplified excerpt of the code:
> {code:java}
> TagInfoAscii EXIF_XP_TITLE_TAG_INFO = new TagInfoAscii("XPTitle", 0x9C9B, -1,
> TiffDirectoryType.EXIF_DIRECTORY_IFD0); //XPTitle (0x9C9B)
> TagInfoAscii EXIF_COPYRIGHT_TAG_INFO = new TagInfoAscii("Copyright", 0x8298,
> -1, TiffDirectoryType.EXIF_DIRECTORY_IFD0); //Copyright (33432, 0x8298)
> …
> TiffOutputSet tiffOutputSet = new TiffOutputSet();
> TiffOutputDirectory exifDirectory = tiffOutputSet.getOrCreateRootDirectory();
> exifDirectory.add(EXIF_XP_TITLE_TAG_INFO, "Gate and Turret");
> exifDirectory.add(EXIF_COPYRIGHT_TAG_INFO, "Copyright © 2009 Garret Wilson");
> …
> new ExifRewriter().updateExifMetadataLossy(byteSource, outputStream,
> tiffOutputSet);
> {code}
> Using [ExifTool|https://exiftool.org/] 12.16 (via
> [ExifToolGUI|https://exiftool.org/gui/) 5.16.0.0], the {{Copyright}} value is
> stored correctly but the {{XPTitle}} is stored as "慇整愠摮吠牵敲t".
> [Metadata++|https://www.logipole.com/metadata++-en.htm] 1.22.14 also shows
> the same corrupted value.
> This is disheartening, as this is nearly the most simple test case possible.
> (Note that [IrfanView|https://www.irfanview.com/] 4.54 can read the
> {{XPTitle}} just fine! Nevertheless ExifTool is the gold standard for image
> metadata reading, and is confirmed by Metadata++. Having an image the
> metadata of which cannot be read in ExifTool is a show-stopper.)
> I'm will attach the test case image to this ticket.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lee updated COMPRESS-565:
---
Attachment: image-2021-02-20-15-51-21-747.png
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Attachments: image-2021-02-20-15-51-21-747.png
>
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #714: true && false String constant
coveralls edited a comment on pull request #714: URL: https://github.com/apache/commons-lang/pull/714#issuecomment-782577897 [](https://coveralls.io/builds/37293610) Coverage remained the same at 94.957% when pulling **e1919d1c75a7ec4fc9f7de9e457615a74c49c8e0 on arturobernalg:feature/boolean_string_const** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] coveralls edited a comment on pull request #714: true && false String constant
coveralls edited a comment on pull request #714: URL: https://github.com/apache/commons-lang/pull/714#issuecomment-782577897 [](https://coveralls.io/builds/37293598) Coverage remained the same at 94.957% when pulling **e1919d1c75a7ec4fc9f7de9e457615a74c49c8e0 on arturobernalg:feature/boolean_string_const** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] coveralls commented on pull request #714: true && false String constant
coveralls commented on pull request #714: URL: https://github.com/apache/commons-lang/pull/714#issuecomment-782577897 [](https://coveralls.io/builds/37293523) Coverage remained the same at 94.957% when pulling **be5c63a4cdd0538ec72fe7cb15448c048603ea4b on arturobernalg:feature/boolean_string_const** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] arturobernalg opened a new pull request #714: true && false String constant
arturobernalg opened a new pull request #714: URL: https://github.com/apache/commons-lang/pull/714 create true && false String constant in order to re use variable, and make the code more readable This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287572#comment-17287572
]
Peter Lee commented on COMPRESS-565:
I see. I can reproduce this issue now.
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (COMPRESS-566) make gzip deflate buffer size configurable
[
https://issues.apache.org/jira/browse/COMPRESS-566?focusedWorklogId=555031=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-555031
]
ASF GitHub Bot logged work on COMPRESS-566:
---
Author: ASF GitHub Bot
Created on: 20/Feb/21 02:07
Start Date: 20/Feb/21 02:07
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on a change in pull request
#168:
URL: https://github.com/apache/commons-compress/pull/168#discussion_r579572525
##
File path:
src/main/java/org/apache/commons/compress/compressors/gzip/GzipParameters.java
##
@@ -118,4 +120,28 @@ public int getOperatingSystem() {
public void setOperatingSystem(final int operatingSystem) {
this.operatingSystem = operatingSystem;
}
+
+/**
+ * Gets size of the buffer used to retrieve compressed data.
+ * @return The size of the buffer used to retrieve compressed data.
+ * @since 1.21
+ * @see #setBufferSize(int)
+ */
+public int getBufferSize() {
+return this.bufferSize;
+}
+
+/**
+ * Sets size of the buffer used to retrieve compressed data from
+ * {@link Deflater} and write to underlying {@link OutputStream}.
+ *
+ * @param bufferSize the bufferSize to set. Must be a positive value.
+ * @since 1.21
+ */
+public void setBufferSize(int bufferSize) {
+if (bufferSize <= 0) {
Review comment:
Do we need a high limit check for `bufferSize` 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 555031)
Time Spent: 1h (was: 50m)
> make gzip deflate buffer size configurable
> --
>
> Key: COMPRESS-566
> URL: https://issues.apache.org/jira/browse/COMPRESS-566
> Project: Commons Compress
> Issue Type: Improvement
> Components: Compressors
>Reporter: Brett Okken
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512.
> It would be good if this could be configurable in GzipParameters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee commented on a change in pull request #168: COMPRESS-566 allow gzip buffer size to be configured
PeterAlfredLee commented on a change in pull request #168:
URL: https://github.com/apache/commons-compress/pull/168#discussion_r579572525
##
File path:
src/main/java/org/apache/commons/compress/compressors/gzip/GzipParameters.java
##
@@ -118,4 +120,28 @@ public int getOperatingSystem() {
public void setOperatingSystem(final int operatingSystem) {
this.operatingSystem = operatingSystem;
}
+
+/**
+ * Gets size of the buffer used to retrieve compressed data.
+ * @return The size of the buffer used to retrieve compressed data.
+ * @since 1.21
+ * @see #setBufferSize(int)
+ */
+public int getBufferSize() {
+return this.bufferSize;
+}
+
+/**
+ * Sets size of the buffer used to retrieve compressed data from
+ * {@link Deflater} and write to underlying {@link OutputStream}.
+ *
+ * @param bufferSize the bufferSize to set. Must be a positive value.
+ * @since 1.21
+ */
+public void setBufferSize(int bufferSize) {
+if (bufferSize <= 0) {
Review comment:
Do we need a high limit check for `bufferSize` 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (COMPRESS-566) make gzip deflate buffer size configurable
[ https://issues.apache.org/jira/browse/COMPRESS-566?focusedWorklogId=554977=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554977 ] ASF GitHub Bot logged work on COMPRESS-566: --- Author: ASF GitHub Bot Created on: 19/Feb/21 23:17 Start Date: 19/Feb/21 23:17 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #168: URL: https://github.com/apache/commons-compress/pull/168#issuecomment-782362631 [](https://coveralls.io/builds/37289516) Coverage increased (+0.005%) to 87.36% when pulling **309681f315008eb78bc063db623e02bbe8c8855c on bokken:COMPRESS-566_buf_size** into **1b7528fbd6295a3958daf1b1114621ee5e40e83c on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554977) Time Spent: 50m (was: 40m) > make gzip deflate buffer size configurable > -- > > Key: COMPRESS-566 > URL: https://issues.apache.org/jira/browse/COMPRESS-566 > Project: Commons Compress > Issue Type: Improvement > Components: Compressors >Reporter: Brett Okken >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512. > It would be good if this could be configurable in GzipParameters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] coveralls edited a comment on pull request #168: COMPRESS-566 allow gzip buffer size to be configured
coveralls edited a comment on pull request #168: URL: https://github.com/apache/commons-compress/pull/168#issuecomment-782362631 [](https://coveralls.io/builds/37289516) Coverage increased (+0.005%) to 87.36% when pulling **309681f315008eb78bc063db623e02bbe8c8855c on bokken:COMPRESS-566_buf_size** into **1b7528fbd6295a3958daf1b1114621ee5e40e83c on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-566) make gzip deflate buffer size configurable
[
https://issues.apache.org/jira/browse/COMPRESS-566?focusedWorklogId=554974=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554974
]
ASF GitHub Bot logged work on COMPRESS-566:
---
Author: ASF GitHub Bot
Created on: 19/Feb/21 23:09
Start Date: 19/Feb/21 23:09
Worklog Time Spent: 10m
Work Description: bokken commented on a change in pull request #168:
URL: https://github.com/apache/commons-compress/pull/168#discussion_r579530866
##
File path:
src/main/java/org/apache/commons/compress/compressors/gzip/GzipParameters.java
##
@@ -118,4 +120,22 @@ public int getOperatingSystem() {
public void setOperatingSystem(final int operatingSystem) {
this.operatingSystem = operatingSystem;
}
+
Review comment:
The rest of the attributes in the class only had javadoc for setter
method. I had started writing javadoc but removed it to match the rest. I can
certainly add.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554974)
Time Spent: 40m (was: 0.5h)
> make gzip deflate buffer size configurable
> --
>
> Key: COMPRESS-566
> URL: https://issues.apache.org/jira/browse/COMPRESS-566
> Project: Commons Compress
> Issue Type: Improvement
> Components: Compressors
>Reporter: Brett Okken
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512.
> It would be good if this could be configurable in GzipParameters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] bokken commented on a change in pull request #168: COMPRESS-566 allow gzip buffer size to be configured
bokken commented on a change in pull request #168:
URL: https://github.com/apache/commons-compress/pull/168#discussion_r579530866
##
File path:
src/main/java/org/apache/commons/compress/compressors/gzip/GzipParameters.java
##
@@ -118,4 +120,22 @@ public int getOperatingSystem() {
public void setOperatingSystem(final int operatingSystem) {
this.operatingSystem = operatingSystem;
}
+
Review comment:
The rest of the attributes in the class only had javadoc for setter
method. I had started writing javadoc but removed it to match the rest. I can
certainly add.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-lang] esend7881 commented on pull request #713: Let mid(null), left(null) and right(null) return empty
esend7881 commented on pull request #713: URL: https://github.com/apache/commons-lang/pull/713#issuecomment-78238 > > [](https://coveralls.io/builds/37285941) > > Coverage decreased (-0.002%) to 94.955% when pulling **821a4a5b04f6fb4bbdcec014be48bf42df5f48ca on esend7881:patch-1** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. > I think that is because the total number of lines have been reduced (smaller denominator) which makes it seem like there is less coverage. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554950=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554950
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 21:44
Start Date: 19/Feb/21 21:44
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #206:
URL: https://github.com/apache/commons-io/pull/206#discussion_r579489683
##
File path:
src/main/java/org/apache/commons/io/output/DeferredFileOutputStream.java
##
@@ -272,4 +274,31 @@ public void writeTo(final OutputStream outputStream)
throws IOException {
}
}
}
+
+/**
+ * Gets the current contents of this byte stream as an {@link InputStream}.
+ * If the data for this output stream has been retained in memory, the
+ * returned stream is backed by buffers of {@code this} stream,
+ * avoiding memory allocation and copy, thus saving space and time.
+ * Otherwise, the returned stream will be one that is created from the data
+ * that has been committed to disk.
+ *
+ * @return the current contents of this output stream.
+ * @throws IOException if this stream is not yet closed or an error occurs.
+ * @see org.apache.commons.io.output.ByteArrayOutputStream#toInputStream()
Review comment:
Needs a Javadoc since tag.
##
File path:
src/test/java/org/apache/commons/io/output/DeferredFileOutputStreamTest.java
##
@@ -365,4 +370,55 @@ private void verifyResultFile(final File testFile) {
fail("Unexpected IOException");
}
}
+
+/**
+ * Tests the case where the amount of data falls below the threshold, and
is therefore confined to memory.
+ * Testing the getInputStream() method.
+ */
+@ParameterizedTest(name = "initialBufferSize = {0}")
+@MethodSource("data")
+public void testBelowThresholdGetInputStream(final int initialBufferSize)
throws IOException {
+final DeferredFileOutputStream dfos = new
DeferredFileOutputStream(testBytes.length + 42, initialBufferSize,
+null);
+try {
+dfos.write(testBytes, 0, testBytes.length);
+dfos.close();
+} catch (final IOException e) {
+fail("Unexpected IOException");
+}
+assertTrue(dfos.isInMemory());
+
+try(InputStream is = dfos.toInputStream()) {
+final byte[] resultBytes = IOUtils.toByteArray(is);
+assertArrayEquals(testBytes, resultBytes);
+}
+}
+
+/**
+ * Tests the case where the amount of data exceeds the threshold, and is
therefore written to disk. The actual data
+ * written to disk is verified, as is the file itself.
+ * Testing the getInputStream() method.
+ */
+@ParameterizedTest(name = "initialBufferSize = {0}")
+@MethodSource("data")
+public void testAboveThresholdGetInputStream(final int initialBufferSize,
@TempDir Path tempDir) throws IOException {
+final File testFile =
tempDir.resolve("testAboveThreshold.dat").toFile();
+
+final DeferredFileOutputStream dfos = new
DeferredFileOutputStream(testBytes.length - 5, initialBufferSize,
+testFile);
+try {
+dfos.write(testBytes, 0, testBytes.length);
+dfos.close();
+} catch (final IOException e) {
+fail("Unexpected IOException");
+}
+assertFalse(dfos.isInMemory());
+
+try(InputStream is = dfos.toInputStream()) {
Review comment:
Missing space after "try".
##
File path:
src/test/java/org/apache/commons/io/output/DeferredFileOutputStreamTest.java
##
@@ -365,4 +370,55 @@ private void verifyResultFile(final File testFile) {
fail("Unexpected IOException");
}
}
+
+/**
+ * Tests the case where the amount of data falls below the threshold, and
is therefore confined to memory.
+ * Testing the getInputStream() method.
+ */
+@ParameterizedTest(name = "initialBufferSize = {0}")
+@MethodSource("data")
+public void testBelowThresholdGetInputStream(final int initialBufferSize)
throws IOException {
+final DeferredFileOutputStream dfos = new
DeferredFileOutputStream(testBytes.length + 42, initialBufferSize,
+null);
+try {
+dfos.write(testBytes, 0, testBytes.length);
+dfos.close();
+} catch (final IOException e) {
+fail("Unexpected IOException");
+}
+assertTrue(dfos.isInMemory());
+
+try(InputStream is = dfos.toInputStream()) {
Review comment:
Missing space after "try".
##
File path:
src/test/java/org/apache/commons/io/output/DeferredFileOutputStreamTest.java
##
@@ -365,4 +370,55 @@ private void verifyResultFile(final File testFile) {
[GitHub] [commons-io] garydgregory commented on a change in pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
garydgregory commented on a change in pull request #206:
URL: https://github.com/apache/commons-io/pull/206#discussion_r579489683
##
File path:
src/main/java/org/apache/commons/io/output/DeferredFileOutputStream.java
##
@@ -272,4 +274,31 @@ public void writeTo(final OutputStream outputStream)
throws IOException {
}
}
}
+
+/**
+ * Gets the current contents of this byte stream as an {@link InputStream}.
+ * If the data for this output stream has been retained in memory, the
+ * returned stream is backed by buffers of {@code this} stream,
+ * avoiding memory allocation and copy, thus saving space and time.
+ * Otherwise, the returned stream will be one that is created from the data
+ * that has been committed to disk.
+ *
+ * @return the current contents of this output stream.
+ * @throws IOException if this stream is not yet closed or an error occurs.
+ * @see org.apache.commons.io.output.ByteArrayOutputStream#toInputStream()
Review comment:
Needs a Javadoc since tag.
##
File path:
src/test/java/org/apache/commons/io/output/DeferredFileOutputStreamTest.java
##
@@ -365,4 +370,55 @@ private void verifyResultFile(final File testFile) {
fail("Unexpected IOException");
}
}
+
+/**
+ * Tests the case where the amount of data falls below the threshold, and
is therefore confined to memory.
+ * Testing the getInputStream() method.
+ */
+@ParameterizedTest(name = "initialBufferSize = {0}")
+@MethodSource("data")
+public void testBelowThresholdGetInputStream(final int initialBufferSize)
throws IOException {
+final DeferredFileOutputStream dfos = new
DeferredFileOutputStream(testBytes.length + 42, initialBufferSize,
+null);
+try {
+dfos.write(testBytes, 0, testBytes.length);
+dfos.close();
+} catch (final IOException e) {
+fail("Unexpected IOException");
+}
+assertTrue(dfos.isInMemory());
+
+try(InputStream is = dfos.toInputStream()) {
+final byte[] resultBytes = IOUtils.toByteArray(is);
+assertArrayEquals(testBytes, resultBytes);
+}
+}
+
+/**
+ * Tests the case where the amount of data exceeds the threshold, and is
therefore written to disk. The actual data
+ * written to disk is verified, as is the file itself.
+ * Testing the getInputStream() method.
+ */
+@ParameterizedTest(name = "initialBufferSize = {0}")
+@MethodSource("data")
+public void testAboveThresholdGetInputStream(final int initialBufferSize,
@TempDir Path tempDir) throws IOException {
+final File testFile =
tempDir.resolve("testAboveThreshold.dat").toFile();
+
+final DeferredFileOutputStream dfos = new
DeferredFileOutputStream(testBytes.length - 5, initialBufferSize,
+testFile);
+try {
+dfos.write(testBytes, 0, testBytes.length);
+dfos.close();
+} catch (final IOException e) {
+fail("Unexpected IOException");
+}
+assertFalse(dfos.isInMemory());
+
+try(InputStream is = dfos.toInputStream()) {
Review comment:
Missing space after "try".
##
File path:
src/test/java/org/apache/commons/io/output/DeferredFileOutputStreamTest.java
##
@@ -365,4 +370,55 @@ private void verifyResultFile(final File testFile) {
fail("Unexpected IOException");
}
}
+
+/**
+ * Tests the case where the amount of data falls below the threshold, and
is therefore confined to memory.
+ * Testing the getInputStream() method.
+ */
+@ParameterizedTest(name = "initialBufferSize = {0}")
+@MethodSource("data")
+public void testBelowThresholdGetInputStream(final int initialBufferSize)
throws IOException {
+final DeferredFileOutputStream dfos = new
DeferredFileOutputStream(testBytes.length + 42, initialBufferSize,
+null);
+try {
+dfos.write(testBytes, 0, testBytes.length);
+dfos.close();
+} catch (final IOException e) {
+fail("Unexpected IOException");
+}
+assertTrue(dfos.isInMemory());
+
+try(InputStream is = dfos.toInputStream()) {
Review comment:
Missing space after "try".
##
File path:
src/test/java/org/apache/commons/io/output/DeferredFileOutputStreamTest.java
##
@@ -365,4 +370,55 @@ private void verifyResultFile(final File testFile) {
fail("Unexpected IOException");
}
}
+
+/**
+ * Tests the case where the amount of data falls below the threshold, and
is therefore confined to memory.
+ * Testing the getInputStream() method.
+ */
+@ParameterizedTest(name = "initialBufferSize = {0}")
+@MethodSource("data")
+public void testBelowThresholdGetInputStream(final int initialBufferSize)
throws
[jira] [Work logged] (COMPRESS-566) make gzip deflate buffer size configurable
[
https://issues.apache.org/jira/browse/COMPRESS-566?focusedWorklogId=554945=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554945
]
ASF GitHub Bot logged work on COMPRESS-566:
---
Author: ASF GitHub Bot
Created on: 19/Feb/21 21:32
Start Date: 19/Feb/21 21:32
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #168:
URL: https://github.com/apache/commons-compress/pull/168#discussion_r579486633
##
File path:
src/main/java/org/apache/commons/compress/compressors/gzip/GzipParameters.java
##
@@ -118,4 +120,22 @@ public int getOperatingSystem() {
public void setOperatingSystem(final int operatingSystem) {
this.operatingSystem = operatingSystem;
}
+
Review comment:
You're missing a Javadoc comment 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554945)
Time Spent: 0.5h (was: 20m)
> make gzip deflate buffer size configurable
> --
>
> Key: COMPRESS-566
> URL: https://issues.apache.org/jira/browse/COMPRESS-566
> Project: Commons Compress
> Issue Type: Improvement
> Components: Compressors
>Reporter: Brett Okken
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512.
> It would be good if this could be configurable in GzipParameters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] garydgregory commented on a change in pull request #168: COMPRESS-566 allow gzip buffer size to be configured
garydgregory commented on a change in pull request #168:
URL: https://github.com/apache/commons-compress/pull/168#discussion_r579486633
##
File path:
src/main/java/org/apache/commons/compress/compressors/gzip/GzipParameters.java
##
@@ -118,4 +120,22 @@ public int getOperatingSystem() {
public void setOperatingSystem(final int operatingSystem) {
this.operatingSystem = operatingSystem;
}
+
Review comment:
You're missing a Javadoc comment 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (COMPRESS-566) make gzip deflate buffer size configurable
[ https://issues.apache.org/jira/browse/COMPRESS-566?focusedWorklogId=554940=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554940 ] ASF GitHub Bot logged work on COMPRESS-566: --- Author: ASF GitHub Bot Created on: 19/Feb/21 21:23 Start Date: 19/Feb/21 21:23 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #168: URL: https://github.com/apache/commons-compress/pull/168#issuecomment-782362631 [](https://coveralls.io/builds/37286781) Coverage increased (+0.005%) to 87.36% when pulling **8797ec4eadc5ad4e0b278677979010ce6aa41f7b on bokken:COMPRESS-566_buf_size** into **1b7528fbd6295a3958daf1b1114621ee5e40e83c on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554940) Time Spent: 20m (was: 10m) > make gzip deflate buffer size configurable > -- > > Key: COMPRESS-566 > URL: https://issues.apache.org/jira/browse/COMPRESS-566 > Project: Commons Compress > Issue Type: Improvement > Components: Compressors >Reporter: Brett Okken >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512. > It would be good if this could be configurable in GzipParameters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] coveralls commented on pull request #168: COMPRESS-566 allow gzip buffer size to be configured
coveralls commented on pull request #168: URL: https://github.com/apache/commons-compress/pull/168#issuecomment-782362631 [](https://coveralls.io/builds/37286781) Coverage increased (+0.005%) to 87.36% when pulling **8797ec4eadc5ad4e0b278677979010ce6aa41f7b on bokken:COMPRESS-566_buf_size** into **1b7528fbd6295a3958daf1b1114621ee5e40e83c on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-566) make gzip deflate buffer size configurable
[ https://issues.apache.org/jira/browse/COMPRESS-566?focusedWorklogId=554937=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554937 ] ASF GitHub Bot logged work on COMPRESS-566: --- Author: ASF GitHub Bot Created on: 19/Feb/21 21:17 Start Date: 19/Feb/21 21:17 Worklog Time Spent: 10m Work Description: bokken opened a new pull request #168: URL: https://github.com/apache/commons-compress/pull/168 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554937) Remaining Estimate: 0h Time Spent: 10m > make gzip deflate buffer size configurable > -- > > Key: COMPRESS-566 > URL: https://issues.apache.org/jira/browse/COMPRESS-566 > Project: Commons Compress > Issue Type: Improvement > Components: Compressors >Reporter: Brett Okken >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512. > It would be good if this could be configurable in GzipParameters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COMPRESS-566) make gzip deflate buffer size configurable
[ https://issues.apache.org/jira/browse/COMPRESS-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287369#comment-17287369 ] Brett Okken commented on COMPRESS-566: -- https://github.com/apache/commons-compress/pull/168 > make gzip deflate buffer size configurable > -- > > Key: COMPRESS-566 > URL: https://issues.apache.org/jira/browse/COMPRESS-566 > Project: Commons Compress > Issue Type: Improvement > Components: Compressors >Reporter: Brett Okken >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512. > It would be good if this could be configurable in GzipParameters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] bokken opened a new pull request #168: COMPRESS-566 allow gzip buffer size to be configured
bokken opened a new pull request #168: URL: https://github.com/apache/commons-compress/pull/168 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (COMPRESS-566) make gzip deflate buffer size configurable
Brett Okken created COMPRESS-566: Summary: make gzip deflate buffer size configurable Key: COMPRESS-566 URL: https://issues.apache.org/jira/browse/COMPRESS-566 Project: Commons Compress Issue Type: Improvement Components: Compressors Reporter: Brett Okken The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512. It would be good if this could be configurable in GzipParameters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #713: Let mid(null), left(null) and right(null) return empty
coveralls edited a comment on pull request #713: URL: https://github.com/apache/commons-lang/pull/713#issuecomment-782338572 [](https://coveralls.io/builds/37285941) Coverage decreased (-0.002%) to 94.955% when pulling **821a4a5b04f6fb4bbdcec014be48bf42df5f48ca on esend7881:patch-1** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] coveralls commented on pull request #713: Let mid(null), left(null) and right(null) return empty
coveralls commented on pull request #713: URL: https://github.com/apache/commons-lang/pull/713#issuecomment-782338572 [](https://coveralls.io/builds/37285868) Coverage decreased (-0.002%) to 94.955% when pulling **821a4a5b04f6fb4bbdcec014be48bf42df5f48ca on esend7881:patch-1** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554908=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554908
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 20:21
Start Date: 19/Feb/21 20:21
Worklog Time Spent: 10m
Work Description: jmark109 commented on pull request #206:
URL: https://github.com/apache/commons-io/pull/206#issuecomment-782320401
@garydgregory I think this is good to go now. Let me know if there are any
other issue.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554908)
Time Spent: 1h 40m (was: 1.5h)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554909=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554909
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 20:21
Start Date: 19/Feb/21 20:21
Worklog Time Spent: 10m
Work Description: jmark109 edited a comment on pull request #206:
URL: https://github.com/apache/commons-io/pull/206#issuecomment-782320401
@garydgregory I think this is good to go now. Let me know if there are any
other issues.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554909)
Time Spent: 1h 50m (was: 1h 40m)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] jmark109 edited a comment on pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
jmark109 edited a comment on pull request #206: URL: https://github.com/apache/commons-io/pull/206#issuecomment-782320401 @garydgregory I think this is good to go now. Let me know if there are any other issues. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] jmark109 commented on pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
jmark109 commented on pull request #206: URL: https://github.com/apache/commons-io/pull/206#issuecomment-782320401 @garydgregory I think this is good to go now. Let me know if there are any other issue. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] esend7881 opened a new pull request #713: Let left(null) and right(null) return empty
esend7881 opened a new pull request #713:
URL: https://github.com/apache/commons-lang/pull/713
I'm not sure if there is reasoning behind `left(null, n)` returning null,
but other `StringUtils` functions tends to return empty strings if their inputs
are null. Likewise, I think it makes sense that `left(null, n)` or `right(null,
n)` returns an empty string instead of returning null. My use case is lambda
logging. I have code like this:
```.java
log.debug("My output (first 256 chars): {}", StringUtils.left(output,
256)::toString);
```
I get an NullPointerExceptions when I do and not properly wrap the call,
etc. So I can't take advantage of both the `left` function as well as lambda
based logging.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554879=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554879
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 19:13
Start Date: 19/Feb/21 19:13
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #206:
URL: https://github.com/apache/commons-io/pull/206#issuecomment-782224839
[](https://coveralls.io/builds/37283381)
Coverage decreased (-0.1%) to 89.254% when pulling
**f424ab6d90fd01a1cad883d3a05c3a409c3a8405 on
jmark109:IO-651_DeferredFileOutputStream_getInputStream** into
**c54bf688e94b550c3ccd4c0789e0b3e00cf1d0ea on apache:master**.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554879)
Time Spent: 1.5h (was: 1h 20m)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] coveralls edited a comment on pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
coveralls edited a comment on pull request #206: URL: https://github.com/apache/commons-io/pull/206#issuecomment-782224839 [](https://coveralls.io/builds/37283381) Coverage decreased (-0.1%) to 89.254% when pulling **f424ab6d90fd01a1cad883d3a05c3a409c3a8405 on jmark109:IO-651_DeferredFileOutputStream_getInputStream** into **c54bf688e94b550c3ccd4c0789e0b3e00cf1d0ea on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554872=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554872
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 18:58
Start Date: 19/Feb/21 18:58
Worklog Time Spent: 10m
Work Description: jmark109 commented on a change in pull request #206:
URL: https://github.com/apache/commons-io/pull/206#discussion_r579407661
##
File path:
src/main/java/org/apache/commons/io/output/DeferredFileOutputStream.java
##
@@ -272,4 +274,27 @@ public void writeTo(final OutputStream outputStream)
throws IOException {
}
}
}
+
+/**
+ * Gets the current contents of this byte stream as an {@link InputStream}.
+ * If the data for this output stream has been retained in memory, the
+ * returned stream is backed by buffers of {@code this} stream,
+ * avoiding memory allocation and copy, thus saving space and time.
+ * Otherwise, the returned stream will be one that is created from the data
+ * that has been committed to disk.
+ *
+ * @return the current contents of this output stream.
+ * @see org.apache.commons.io.output.ByteArrayOutputStream.toInputStream()
Review comment:
Ok, I see it now. I needed to run the `javadoc:javadoc` goal. I haven't
used maven default goals before, so I was just running `package` and `test`
manually.
It should be fixed now. Sorry for the confusion.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554872)
Time Spent: 1h 20m (was: 1h 10m)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] jmark109 commented on a change in pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
jmark109 commented on a change in pull request #206:
URL: https://github.com/apache/commons-io/pull/206#discussion_r579407661
##
File path:
src/main/java/org/apache/commons/io/output/DeferredFileOutputStream.java
##
@@ -272,4 +274,27 @@ public void writeTo(final OutputStream outputStream)
throws IOException {
}
}
}
+
+/**
+ * Gets the current contents of this byte stream as an {@link InputStream}.
+ * If the data for this output stream has been retained in memory, the
+ * returned stream is backed by buffers of {@code this} stream,
+ * avoiding memory allocation and copy, thus saving space and time.
+ * Otherwise, the returned stream will be one that is created from the data
+ * that has been committed to disk.
+ *
+ * @return the current contents of this output stream.
+ * @see org.apache.commons.io.output.ByteArrayOutputStream.toInputStream()
Review comment:
Ok, I see it now. I needed to run the `javadoc:javadoc` goal. I haven't
used maven default goals before, so I was just running `package` and `test`
manually.
It should be fixed now. Sorry for the confusion.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554866=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554866
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 18:39
Start Date: 19/Feb/21 18:39
Worklog Time Spent: 10m
Work Description: XenoAmess commented on a change in pull request #206:
URL: https://github.com/apache/commons-io/pull/206#discussion_r579396064
##
File path:
src/main/java/org/apache/commons/io/output/DeferredFileOutputStream.java
##
@@ -272,4 +274,27 @@ public void writeTo(final OutputStream outputStream)
throws IOException {
}
}
}
+
+/**
+ * Gets the current contents of this byte stream as an {@link InputStream}.
+ * If the data for this output stream has been retained in memory, the
+ * returned stream is backed by buffers of {@code this} stream,
+ * avoiding memory allocation and copy, thus saving space and time.
+ * Otherwise, the returned stream will be one that is created from the data
+ * that has been committed to disk.
+ *
+ * @return the current contents of this output stream.
+ * @see org.apache.commons.io.output.ByteArrayOutputStream.toInputStream()
Review comment:
@see org.apache.commons.io.output.ByteArrayOutputStream#toInputStream()
##
File path:
src/main/java/org/apache/commons/io/output/DeferredFileOutputStream.java
##
@@ -272,4 +274,27 @@ public void writeTo(final OutputStream outputStream)
throws IOException {
}
}
}
+
+/**
+ * Gets the current contents of this byte stream as an {@link InputStream}.
+ * If the data for this output stream has been retained in memory, the
+ * returned stream is backed by buffers of {@code this} stream,
+ * avoiding memory allocation and copy, thus saving space and time.
+ * Otherwise, the returned stream will be one that is created from the data
+ * that has been committed to disk.
+ *
+ * @return the current contents of this output stream.
+ * @see org.apache.commons.io.output.ByteArrayOutputStream.toInputStream()
Review comment:
```@see
org.apache.commons.io.output.ByteArrayOutputStream#toInputStream()```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554866)
Time Spent: 1h 10m (was: 1h)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] XenoAmess commented on a change in pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
XenoAmess commented on a change in pull request #206:
URL: https://github.com/apache/commons-io/pull/206#discussion_r579396064
##
File path:
src/main/java/org/apache/commons/io/output/DeferredFileOutputStream.java
##
@@ -272,4 +274,27 @@ public void writeTo(final OutputStream outputStream)
throws IOException {
}
}
}
+
+/**
+ * Gets the current contents of this byte stream as an {@link InputStream}.
+ * If the data for this output stream has been retained in memory, the
+ * returned stream is backed by buffers of {@code this} stream,
+ * avoiding memory allocation and copy, thus saving space and time.
+ * Otherwise, the returned stream will be one that is created from the data
+ * that has been committed to disk.
+ *
+ * @return the current contents of this output stream.
+ * @see org.apache.commons.io.output.ByteArrayOutputStream.toInputStream()
Review comment:
@see org.apache.commons.io.output.ByteArrayOutputStream#toInputStream()
##
File path:
src/main/java/org/apache/commons/io/output/DeferredFileOutputStream.java
##
@@ -272,4 +274,27 @@ public void writeTo(final OutputStream outputStream)
throws IOException {
}
}
}
+
+/**
+ * Gets the current contents of this byte stream as an {@link InputStream}.
+ * If the data for this output stream has been retained in memory, the
+ * returned stream is backed by buffers of {@code this} stream,
+ * avoiding memory allocation and copy, thus saving space and time.
+ * Otherwise, the returned stream will be one that is created from the data
+ * that has been committed to disk.
+ *
+ * @return the current contents of this output stream.
+ * @see org.apache.commons.io.output.ByteArrayOutputStream.toInputStream()
Review comment:
```@see
org.apache.commons.io.output.ByteArrayOutputStream#toInputStream()```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554861=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554861
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 18:22
Start Date: 19/Feb/21 18:22
Worklog Time Spent: 10m
Work Description: jmark109 commented on pull request #206:
URL: https://github.com/apache/commons-io/pull/206#issuecomment-782252971
@garydgregory I just ran `mvn package` again and it was successful. I don't
see any errors.
I also tried running `mvn test` just to make sure, and no errors either.
What errors do you see?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554861)
Time Spent: 1h (was: 50m)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] jmark109 commented on pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
jmark109 commented on pull request #206: URL: https://github.com/apache/commons-io/pull/206#issuecomment-782252971 @garydgregory I just ran `mvn package` again and it was successful. I don't see any errors. I also tried running `mvn test` just to make sure, and no errors either. What errors do you see? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554846=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554846
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 17:48
Start Date: 19/Feb/21 17:48
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #206:
URL: https://github.com/apache/commons-io/pull/206#issuecomment-782232501
> @garydgregory Yes, I see that. I don't think these failures have anything
to do with my changes. Looks like some type of misconfiguration with the build.
I see errors like this:
>
> ```
> java.lang.IllegalAccessError: class
org.apache.commons.io.input.BufferedFileChannelInputStream (in unnamed module
@0x685f4c2e) cannot access class sun.nio.ch.DirectBuffer (in module java.base)
because module java.base does not export sun.nio.ch to unnamed module
@0x685f4c2e
> ```
>
> I did not touch that class. I only added one new method to
`DeferredFileOutputStream` so it should not affect any other tests.
>
> When I build locally everything works fine.
Just run the default maven goal and you will see Javadoc errors.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554846)
Time Spent: 50m (was: 40m)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] garydgregory commented on pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
garydgregory commented on pull request #206: URL: https://github.com/apache/commons-io/pull/206#issuecomment-782232501 > @garydgregory Yes, I see that. I don't think these failures have anything to do with my changes. Looks like some type of misconfiguration with the build. I see errors like this: > > ``` > java.lang.IllegalAccessError: class org.apache.commons.io.input.BufferedFileChannelInputStream (in unnamed module @0x685f4c2e) cannot access class sun.nio.ch.DirectBuffer (in module java.base) because module java.base does not export sun.nio.ch to unnamed module @0x685f4c2e > ``` > > I did not touch that class. I only added one new method to `DeferredFileOutputStream` so it should not affect any other tests. > > When I build locally everything works fine. Just run the default maven goal and you will see Javadoc errors. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554845=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554845
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 17:41
Start Date: 19/Feb/21 17:41
Worklog Time Spent: 10m
Work Description: jmark109 commented on pull request #206:
URL: https://github.com/apache/commons-io/pull/206#issuecomment-782228140
@garydgregory Yes, I see that. I don't think these failures have anything to
do with my changes. Looks like some type of misconfiguration with the build. I
see errors like this:
```
java.lang.IllegalAccessError: class
org.apache.commons.io.input.BufferedFileChannelInputStream (in unnamed module
@0x685f4c2e) cannot access class sun.nio.ch.DirectBuffer (in module java.base)
because module java.base does not export sun.nio.ch to unnamed module
@0x685f4c2e
```
I did not touch that class. I only added one new method to
`DeferredFileOutputStream` so it should not affect any other tests.
When I build locally everything works fine.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554845)
Time Spent: 40m (was: 0.5h)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] jmark109 commented on pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
jmark109 commented on pull request #206: URL: https://github.com/apache/commons-io/pull/206#issuecomment-782228140 @garydgregory Yes, I see that. I don't think these failures have anything to do with my changes. Looks like some type of misconfiguration with the build. I see errors like this: ``` java.lang.IllegalAccessError: class org.apache.commons.io.input.BufferedFileChannelInputStream (in unnamed module @0x685f4c2e) cannot access class sun.nio.ch.DirectBuffer (in module java.base) because module java.base does not export sun.nio.ch to unnamed module @0x685f4c2e ``` I did not touch that class. I only added one new method to `DeferredFileOutputStream` so it should not affect any other tests. When I build locally everything works fine. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554841=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554841
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 17:36
Start Date: 19/Feb/21 17:36
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #206:
URL: https://github.com/apache/commons-io/pull/206#issuecomment-782225559
@jmark109
This PR causes build failures.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554841)
Time Spent: 0.5h (was: 20m)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] garydgregory commented on pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
garydgregory commented on pull request #206: URL: https://github.com/apache/commons-io/pull/206#issuecomment-782225559 @jmark109 This PR causes build failures. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554839=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554839
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 17:35
Start Date: 19/Feb/21 17:35
Worklog Time Spent: 10m
Work Description: coveralls commented on pull request #206:
URL: https://github.com/apache/commons-io/pull/206#issuecomment-782224839
[](https://coveralls.io/builds/37280798)
Coverage decreased (-0.1%) to 89.254% when pulling
**6f50f16c23702947c9d928370ab4f2e585ecfd38 on
jmark109:IO-651_DeferredFileOutputStream_getInputStream** into
**c54bf688e94b550c3ccd4c0789e0b3e00cf1d0ea on apache:master**.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554839)
Time Spent: 20m (was: 10m)
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] coveralls commented on pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
coveralls commented on pull request #206: URL: https://github.com/apache/commons-io/pull/206#issuecomment-782224839 [](https://coveralls.io/builds/37280798) Coverage decreased (-0.1%) to 89.254% when pulling **6f50f16c23702947c9d928370ab4f2e585ecfd38 on jmark109:IO-651_DeferredFileOutputStream_getInputStream** into **c54bf688e94b550c3ccd4c0789e0b3e00cf1d0ea on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-651) Provide method to retrieve data from DeferredFileOutputStream as InputStream
[
https://issues.apache.org/jira/browse/IO-651?focusedWorklogId=554813=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554813
]
ASF GitHub Bot logged work on IO-651:
-
Author: ASF GitHub Bot
Created on: 19/Feb/21 16:39
Start Date: 19/Feb/21 16:39
Worklog Time Spent: 10m
Work Description: jmark109 opened a new pull request #206:
URL: https://github.com/apache/commons-io/pull/206
Add DeferredFileOutputStream.getInputStream() for efficient retrieval of
OutputSteam data.
Fixes IO-651.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 554813)
Remaining Estimate: 0h
Time Spent: 10m
> Provide method to retrieve data from DeferredFileOutputStream as InputStream
>
>
> Key: IO-651
> URL: https://issues.apache.org/jira/browse/IO-651
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: John Mark
>Priority: Major
> Labels: easyfix, performance, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It would be very helpful to have to {{toInputStream()}} method on the
> {{DeferredFileOutputStream}} class. Besides for convenience, it would allow
> for improved efficiency since in the case of in-memory data the byte buffer
> would not need to be copied (as opposed to the current {{getData()}} method).
> The implementation is pretty simple and can be something like the following
> (based on the current {{writeTo(OutputStream)}} method):
> {code:java}
> public InputStream toInputStream() throws IOException {
> if (!closed) {
> throw new IOException("Stream not closed");
> }
> if (isInMemory()) {
> return memoryOutputStream.toInputStream();
> } else {
> return Files.newInputStream(outputFile.toPath());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] jmark109 opened a new pull request #206: IO-651 Add DeferredFileOutputStream.getInputStream()
jmark109 opened a new pull request #206: URL: https://github.com/apache/commons-io/pull/206 Add DeferredFileOutputStream.getInputStream() for efficient retrieval of OutputSteam data. Fixes IO-651. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
[
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287159#comment-17287159
]
Melloware commented on IO-663:
--
Nope all i did was swap out 2.6 for 2.9.0-SNAPSHOT in our app and it failed
catstrophically. All with "Missing files". So i am looking and directories
are empty like it didn't copy the files or copied them so my app can't see
them. So whatever it was it didn't make it better.
> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another)
> between the similar methods in commons IO, codehaus-plexus-utils, and
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in
> maven-release:
> {{// copy poms so tests are valid without clean}}
> {{ File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
> {{ File testDir = getTestFile( "target/test-classes" + projectPath );}}
> {{ FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
> The process cannot access the file because it is being used by another
> process
> "The process cannot access the file because it is being used by another
> process" I think points to the root of the bug. This is a Windows file system
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory
> from both maven-shared-utils and commons-io, all of which failed in the same
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same
> when copying files on Windows as on Linux and Mac OS X.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-csv] coveralls edited a comment on pull request #118: Bump opencsv from 5.2 to 5.3
coveralls edited a comment on pull request #118: URL: https://github.com/apache/commons-csv/pull/118#issuecomment-716345707 [](https://coveralls.io/builds/37276392) Coverage remained the same at 98.454% when pulling **1550ad7b34286d0818ce399eb98468c54161a39e on dependabot/maven/com.opencsv-opencsv-5.3** into **69db7d14f7f9e1f1dd0302812240bc5e4f85ebd9 on master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (IMAGING-281) Simple Exif XPTitle corrupted.
[
https://issues.apache.org/jira/browse/IMAGING-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson closed IMAGING-281.
-
> Simple Exif XPTitle corrupted.
> --
>
> Key: IMAGING-281
> URL: https://issues.apache.org/jira/browse/IMAGING-281
> Project: Commons Imaging
> Issue Type: Bug
>Affects Versions: 1.0-alpha2
>Reporter: Garret Wilson
>Priority: Blocker
> Attachments: gate-turret-exif-bad-title.jpg
>
>
> I have a small input JPEG image containing _no metadata sections whatsoever_.
> I use Apache Commons Imaging 1.0-alpha2 to add two simple Exif {{IFD0}}
> properties using
> [{{ExifRewriter().updateExifMetadataLossy()}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.html#updateExifMetadataLossy-org.apache.commons.imaging.common.bytesource.ByteSource-java.io.OutputStream-org.apache.commons.imaging.formats.tiff.write.TiffOutputSet-].
> * {{XPTitle}} ({{0x9C9B}}): "Gate and Turret"
> * {{Copyright}} ({{33432}}, {{0x8298}}): "Copyright © 2009 Garret Wilson"
> Here is a simplified excerpt of the code:
> {code:java}
> TagInfoAscii EXIF_XP_TITLE_TAG_INFO = new TagInfoAscii("XPTitle", 0x9C9B, -1,
> TiffDirectoryType.EXIF_DIRECTORY_IFD0); //XPTitle (0x9C9B)
> TagInfoAscii EXIF_COPYRIGHT_TAG_INFO = new TagInfoAscii("Copyright", 0x8298,
> -1, TiffDirectoryType.EXIF_DIRECTORY_IFD0); //Copyright (33432, 0x8298)
> …
> TiffOutputSet tiffOutputSet = new TiffOutputSet();
> TiffOutputDirectory exifDirectory = tiffOutputSet.getOrCreateRootDirectory();
> exifDirectory.add(EXIF_XP_TITLE_TAG_INFO, "Gate and Turret");
> exifDirectory.add(EXIF_COPYRIGHT_TAG_INFO, "Copyright © 2009 Garret Wilson");
> …
> new ExifRewriter().updateExifMetadataLossy(byteSource, outputStream,
> tiffOutputSet);
> {code}
> Using [ExifTool|https://exiftool.org/] 12.16 (via
> [ExifToolGUI|https://exiftool.org/gui/) 5.16.0.0], the {{Copyright}} value is
> stored correctly but the {{XPTitle}} is stored as "慇整愠摮吠牵敲t".
> [Metadata++|https://www.logipole.com/metadata++-en.htm] 1.22.14 also shows
> the same corrupted value.
> This is disheartening, as this is nearly the most simple test case possible.
> (Note that [IrfanView|https://www.irfanview.com/] 4.54 can read the
> {{XPTitle}} just fine! Nevertheless ExifTool is the gold standard for image
> metadata reading, and is confirmed by Metadata++. Having an image the
> metadata of which cannot be read in ExifTool is a show-stopper.)
> I'm will attach the test case image to this ticket.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IMAGING-281) Simple Exif XPTitle corrupted.
[
https://issues.apache.org/jira/browse/IMAGING-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson resolved IMAGING-281.
---
Resolution: Not A Problem
Good news: I found the source of the problem.
It seems that Microsoft stores the XP tags, including {{XPTitle}}, not as UTF-8
but as UCS-2. (See [ExifTool FAQ on
charsets|https://exiftool.org/faq.html#Q10].) Thus in Apache Commons Imaging I
should have been using {{TagInfoXpString}} instead of {{TagInfoAscii}}, like
this:
{code:java}
TagInfoXpString EXIF_TAG_XP_TITLE = new TagInfoXpString("XPTitle", 0x9C9B,
TiffDirectoryType.EXIF_DIRECTORY_IFD0);
{code}
The other libraries, which knew about the XP tag encoding, had been been trying
to read the UTF-8 value as a two-byte Unicode encoding, which is what resulted
in the corrupted string. (I'm not sure why Irfan view managed to read it. Maybe
it went out of its way to detect UTF-8 before trying UCS-2 or UTF-16LE, or
maybe it is just written incorrectly and was making the same mistaken
assumption I made.)
I'll close this ticket as not a problem.
> Simple Exif XPTitle corrupted.
> --
>
> Key: IMAGING-281
> URL: https://issues.apache.org/jira/browse/IMAGING-281
> Project: Commons Imaging
> Issue Type: Bug
>Affects Versions: 1.0-alpha2
>Reporter: Garret Wilson
>Priority: Blocker
> Attachments: gate-turret-exif-bad-title.jpg
>
>
> I have a small input JPEG image containing _no metadata sections whatsoever_.
> I use Apache Commons Imaging 1.0-alpha2 to add two simple Exif {{IFD0}}
> properties using
> [{{ExifRewriter().updateExifMetadataLossy()}}|https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/formats/jpeg/exif/ExifRewriter.html#updateExifMetadataLossy-org.apache.commons.imaging.common.bytesource.ByteSource-java.io.OutputStream-org.apache.commons.imaging.formats.tiff.write.TiffOutputSet-].
> * {{XPTitle}} ({{0x9C9B}}): "Gate and Turret"
> * {{Copyright}} ({{33432}}, {{0x8298}}): "Copyright © 2009 Garret Wilson"
> Here is a simplified excerpt of the code:
> {code:java}
> TagInfoAscii EXIF_XP_TITLE_TAG_INFO = new TagInfoAscii("XPTitle", 0x9C9B, -1,
> TiffDirectoryType.EXIF_DIRECTORY_IFD0); //XPTitle (0x9C9B)
> TagInfoAscii EXIF_COPYRIGHT_TAG_INFO = new TagInfoAscii("Copyright", 0x8298,
> -1, TiffDirectoryType.EXIF_DIRECTORY_IFD0); //Copyright (33432, 0x8298)
> …
> TiffOutputSet tiffOutputSet = new TiffOutputSet();
> TiffOutputDirectory exifDirectory = tiffOutputSet.getOrCreateRootDirectory();
> exifDirectory.add(EXIF_XP_TITLE_TAG_INFO, "Gate and Turret");
> exifDirectory.add(EXIF_COPYRIGHT_TAG_INFO, "Copyright © 2009 Garret Wilson");
> …
> new ExifRewriter().updateExifMetadataLossy(byteSource, outputStream,
> tiffOutputSet);
> {code}
> Using [ExifTool|https://exiftool.org/] 12.16 (via
> [ExifToolGUI|https://exiftool.org/gui/) 5.16.0.0], the {{Copyright}} value is
> stored correctly but the {{XPTitle}} is stored as "慇整愠摮吠牵敲t".
> [Metadata++|https://www.logipole.com/metadata++-en.htm] 1.22.14 also shows
> the same corrupted value.
> This is disheartening, as this is nearly the most simple test case possible.
> (Note that [IrfanView|https://www.irfanview.com/] 4.54 can read the
> {{XPTitle}} just fine! Nevertheless ExifTool is the gold standard for image
> metadata reading, and is confirmed by Metadata++. Having an image the
> metadata of which cannot be read in ExifTool is a show-stopper.)
> I'm will attach the test case image to this ticket.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-csv] coveralls commented on pull request #133: Bump junit-jupiter from 5.7.0 to 5.7.1
coveralls commented on pull request #133: URL: https://github.com/apache/commons-csv/pull/133#issuecomment-782129151 [](https://coveralls.io/builds/37276288) Coverage remained the same at 98.454% when pulling **8a26899285886d9812cdcba2bf62273bf8fe1cb2 on dependabot/maven/org.junit.jupiter-junit-jupiter-5.7.1** into **69db7d14f7f9e1f1dd0302812240bc5e4f85ebd9 on master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1614) Split fixed-length elements
[ https://issues.apache.org/jira/browse/LANG-1614?focusedWorklogId=554786=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554786 ] ASF GitHub Bot logged work on LANG-1614: Author: ASF GitHub Bot Created on: 19/Feb/21 14:51 Start Date: 19/Feb/21 14:51 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #693: URL: https://github.com/apache/commons-lang/pull/693#issuecomment-755237313 [](https://coveralls.io/builds/37276028) Coverage increased (+0.005%) to 94.962% when pulling **3d73ca9dfa1e33da76d2ee6c54e4994f422b83de on arturobernalg:feature/LANG-1614** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554786) Time Spent: 1h 50m (was: 1h 40m) > Split fixed-length elements > --- > > Key: LANG-1614 > URL: https://issues.apache.org/jira/browse/LANG-1614 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.11 >Reporter: Arturo Bernal >Priority: Minor > Labels: StringUtils, improvement, pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Create a new method that split a string into an array of fixed-length elements -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #693: [LANG-1614] - Split fixed-length elements
coveralls edited a comment on pull request #693: URL: https://github.com/apache/commons-lang/pull/693#issuecomment-755237313 [](https://coveralls.io/builds/37276028) Coverage increased (+0.005%) to 94.962% when pulling **3d73ca9dfa1e33da76d2ee6c54e4994f422b83de on arturobernalg:feature/LANG-1614** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] garydgregory commented on pull request #118: Bump opencsv from 5.2 to 5.3
garydgregory commented on pull request #118: URL: https://github.com/apache/commons-csv/pull/118#issuecomment-782100023 @dependabot rebase This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] garydgregory commented on pull request #133: Bump junit-jupiter from 5.7.0 to 5.7.1
garydgregory commented on pull request #133: URL: https://github.com/apache/commons-csv/pull/133#issuecomment-782099782 @dependabot rebase This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] garydgregory merged pull request #129: Bump mockito-core from 3.7.0 to 3.7.7
garydgregory merged pull request #129: URL: https://github.com/apache/commons-csv/pull/129 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] dependabot[bot] opened a new pull request #133: Bump junit-jupiter from 5.7.0 to 5.7.1
dependabot[bot] opened a new pull request #133: URL: https://github.com/apache/commons-csv/pull/133 Bumps [junit-jupiter](https://github.com/junit-team/junit5) from 5.7.0 to 5.7.1. Release notes Sourced from https://github.com/junit-team/junit5/releases;>junit-jupiter's releases. JUnit 5.7.1 = Platform 1.7.1 + Jupiter 5.7.1 + Vintage 5.7.1 See http://junit.org/junit5/docs/5.7.1/release-notes/;>Release Notes. Commits https://github.com/junit-team/junit5/commit/b5227801590b3a0758c46a4890e6784f7b04649c;>b522780 Release 5.7.1 https://github.com/junit-team/junit5/commit/f8c6d4ab7919781ea7401eac2caeac55c5d99d59;>f8c6d4a Finalize release notes for 5.7.1 https://github.com/junit-team/junit5/commit/8b3d5aa0885f1e0a38283de71c7431a77f234cde;>8b3d5aa Fix container failure XML reporting (https://github-redirect.dependabot.com/junit-team/junit5/issues/2542;>#2542) https://github.com/junit-team/junit5/commit/b394ef08ad2493494032ef9179cbd050e21a614c;>b394ef0 Use jOOX to test XML reports https://github.com/junit-team/junit5/commit/2b7d5b12c19da96eebd37e11ef90df4ebfc0fbed;>2b7d5b1 Use Java 9 collection factory methods https://github.com/junit-team/junit5/commit/5c42adb2b44b3532f5e8563d19d044597e4d8c4f;>5c42adb Fix typos https://github.com/junit-team/junit5/commit/beddaf450158fd81bf0da9400efb5e1d25eedba9;>beddaf4 Remove unnecessary throws clause https://github.com/junit-team/junit5/commit/85ee2126196c403dab7e05b904a84c05bf58f0db;>85ee212 Simplify assertions https://github.com/junit-team/junit5/commit/c704713e51ddfc3e2a7f811db939702a4350fb65;>c704713 Fix assertion https://github.com/junit-team/junit5/commit/7d6edad19aedae80ce5484dc8677390baac768f8;>7d6edad Convert field to local variable Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.7.0...r5.7.1;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] garydgregory merged pull request #132: Bump actions/cache from v2 to v2.1.4
garydgregory merged pull request #132: URL: https://github.com/apache/commons-csv/pull/132 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] garydgregory merged pull request #131: Bump maven-checkstyle-plugin from 3.1.1 to 3.1.2
garydgregory merged pull request #131: URL: https://github.com/apache/commons-csv/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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1614) Split fixed-length elements
[ https://issues.apache.org/jira/browse/LANG-1614?focusedWorklogId=554741=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554741 ] ASF GitHub Bot logged work on LANG-1614: Author: ASF GitHub Bot Created on: 19/Feb/21 13:33 Start Date: 19/Feb/21 13:33 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #693: URL: https://github.com/apache/commons-lang/pull/693#issuecomment-755237313 [](https://coveralls.io/builds/37274158) Coverage increased (+0.005%) to 94.962% when pulling **fac0c95752363418acdb12e24c7014ba251d2fb7 on arturobernalg:feature/LANG-1614** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554741) Time Spent: 1h 40m (was: 1.5h) > Split fixed-length elements > --- > > Key: LANG-1614 > URL: https://issues.apache.org/jira/browse/LANG-1614 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.11 >Reporter: Arturo Bernal >Priority: Minor > Labels: StringUtils, improvement, pull-request-available > Time Spent: 1h 40m > Remaining Estimate: 0h > > Create a new method that split a string into an array of fixed-length elements -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #693: [LANG-1614] - Split fixed-length elements
coveralls edited a comment on pull request #693: URL: https://github.com/apache/commons-lang/pull/693#issuecomment-755237313 [](https://coveralls.io/builds/37274158) Coverage increased (+0.005%) to 94.962% when pulling **fac0c95752363418acdb12e24c7014ba251d2fb7 on arturobernalg:feature/LANG-1614** into **5689c91cf2a3a27f0a3a8a362857f2cf0919d4f6 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1614) Split fixed-length elements
[ https://issues.apache.org/jira/browse/LANG-1614?focusedWorklogId=554739=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554739 ] ASF GitHub Bot logged work on LANG-1614: Author: ASF GitHub Bot Created on: 19/Feb/21 13:21 Start Date: 19/Feb/21 13:21 Worklog Time Spent: 10m Work Description: arturobernalg commented on pull request #693: URL: https://github.com/apache/commons-lang/pull/693#issuecomment-782070022 any thoughts here @garydgregory ;) should/could it added to commons-lang? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554739) Time Spent: 1.5h (was: 1h 20m) > Split fixed-length elements > --- > > Key: LANG-1614 > URL: https://issues.apache.org/jira/browse/LANG-1614 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.11 >Reporter: Arturo Bernal >Priority: Minor > Labels: StringUtils, improvement, pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Create a new method that split a string into an array of fixed-length elements -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] arturobernalg commented on pull request #693: [LANG-1614] - Split fixed-length elements
arturobernalg commented on pull request #693: URL: https://github.com/apache/commons-lang/pull/693#issuecomment-782070022 any thoughts here @garydgregory ;) should/could it added to commons-lang? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-statistics] aherbert commented on a change in pull request #26: Add truncated normal distribution.
aherbert commented on a change in pull request #26:
URL: https://github.com/apache/commons-statistics/pull/26#discussion_r579159518
##
File path:
commons-statistics-distribution/src/test/java/org/apache/commons/statistics/distribution/TruncatedNormalDistributionTest.java
##
@@ -0,0 +1,283 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.statistics.distribution;
+
+import org.junit.jupiter.api.Assertions;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+
+/**
+ * Test class for {@link TruncatedNormalDistribution}.
+ * All test values were computed using Python with SciPy v1.6.0.
+ */
+class TruncatedNormalDistributionTest extends
ContinuousDistributionAbstractTest {
+/**
+ * Default tolerance.
+ */
+private static final double TOLERANCE = 1e-7;
+
+/**
+ * Distribution to test with.
+ */
+private TruncatedNormalDistribution distribution = new
TruncatedNormalDistribution(1.9, 1.3, -1.1, 3.4);
+/**
+ * Percentiles to test with.
+ */
+private double[] ppfValues = new double[]{0, 0.0001, 0.001, 0.01, 0.025,
0.05, 0.1, 0.25, 0.5, 0.75, 0.9, 0.95,
+ 0.975, 0.99, 0.999, 0., 1};
+/**
+ * Expected cumulative values for percentiles.
+ */
+private double[] cdfValues = new double[]{-1.1, -1.09597275767544,
-1.0609616183922, -0.79283350106842,
+ -0.505331829887808,
-0.192170173599874, 0.21173317261645,
+ 0.925791281910463,
1.71399518338879, 2.43413009451536, 2.94473113856785,
+ 3.15310057075828,
3.27036798398733, 3.34641874981679, 3.39452729074341,
+ 3.39945153287941, 3.4};
+/**
+ * Expected density values for percentiles.
+ */
+private double[] pdfValues = new double[]{0.0247422752302618,
0.0249196707321102, 0.0265057408263321,
+ 0.0415071096500185,
0.0640403254340905, 0.0971457789636,
+ 0.152622492901864,
0.267853863255995, 0.35107475879338, 0.325977522502844,
+ 0.25680502248913,
0.222886115806507, 0.203494915087054, 0.19099794992,
+ 0.183167918885238,
0.182370706542209, 0.182281965373914};
+/**
+ * Expected distribution mean.
+ */
+private double mean = 1.63375792365723;
+/**
+ * Expected distribution variance.
+ */
+private double variance = 1.03158703914439;
+
+/**
+ * Overrides tolerance and sets up distribution.
+ */
+@BeforeEach
+void setUp() {
+setTolerance(TOLERANCE);
+super.setUp();
+}
+
+/**
+ * {@inheritDoc}
+ */
+@Override
+public ContinuousDistribution makeDistribution() {
+return distribution;
+}
+
+/**
+ * {@inheritDoc}
+ */
+@Override
+public double[] makeCumulativeTestPoints() {
+return cdfValues;
+}
+
+/**
+ * {@inheritDoc}
+ */
+@Override
+public double[] makeCumulativeTestValues() {
+return ppfValues;
+}
+
+/**
+ * {@inheritDoc}
+ */
+@Override
+public double[] makeDensityTestValues() {
+return pdfValues;
+}
+
+/**
+ * Configures new test values and runs relevant tests in this class and
{@link ContinuousDistributionAbstractTest}.
+ * @param testDistribution distribution to test with.
+ * @param expectedPpfValues expected percentiles to test with.
+ * @param expectedCdfValues expected cumulative values for percentiles.
+ * @param expectedPdfValues expected density values for percentiles.
+ * @param expectedMean expected mean.
+ * @param expectedVariance expected variance.
+ */
+private void testAdditionalDistribution(
+TruncatedNormalDistribution testDistribution,
+double[] expectedPpfValues,
+double[] expectedCdfValues,
+double[] expectedPdfValues,
+double expectedMean,
[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
[
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287062#comment-17287062
]
Melloware commented on IO-663:
--
[~ggregory] I got permission from my client to test the SNAPSHOT version. We
are going to put it on two of our servers and monitor for at least a week or
more.
> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another)
> between the similar methods in commons IO, codehaus-plexus-utils, and
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in
> maven-release:
> {{// copy poms so tests are valid without clean}}
> {{ File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
> {{ File testDir = getTestFile( "target/test-classes" + projectPath );}}
> {{ FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
> The process cannot access the file because it is being used by another
> process
> "The process cannot access the file because it is being used by another
> process" I think points to the root of the bug. This is a Windows file system
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory
> from both maven-shared-utils and commons-io, all of which failed in the same
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same
> when copying files on Windows as on Linux and Mac OS X.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-statistics] aherbert commented on pull request #26: Add truncated normal distribution.
aherbert commented on pull request #26:
URL: https://github.com/apache/commons-statistics/pull/26#issuecomment-782051472
Thanks for the contribution. The implementation and tests look good (all
edge cases are covered).
The code is currently failing PMD checks. Most of these are for missing the
`final` keyword on local variables. You can see the PMD errors by running:
```
mvn pmd:pmd
```
Then open the file in `target/site/pmd.html`
There is also an error for a confusing ternary. I think it is OK in this
context but to avoid the issue what do you think to rewriting the constructor
as:
```java
if (lower == Double.NEGATIVE_INFINITY) {
if (upper == Double.POSITIVE_INFINITY) {
// No truncation
this.mean = mean;
variance = sd * sd;
} else {
// One-sided lower tail truncation
double betaRatio = pdfBeta / cdfBeta;
this.mean = mean - sd * betaRatio;
variance = sd * sd * (1 - beta * betaRatio - betaRatio *
betaRatio);
}
} else {
if (upper == Double.POSITIVE_INFINITY) {
// One-sided upper tail truncation
double alphaRatio = pdfAlpha / cdfDelta;
this.mean = mean + sd * alphaRatio;
variance = sd * sd * (1 + alpha * alphaRatio - alphaRatio *
alphaRatio);
} else {
// Two-sided truncation
this.mean = mean + pdfCdfDelta * parentSd;
variance = sd * sd * (1 + alphaBetaDelta - pdfCdfDelta *
pdfCdfDelta);
}
}
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286988#comment-17286988
]
Evgeny Bovykin commented on COMPRESS-565:
-
??Is the input.bin an empty file with size of 5GB???
Yes. Your code seems to be ok.
??I'm testing on Ubuntu and I can successfully extract the generated output.zip
using _unzip_ command without reporting any errors.??
Yes, some tools ignore the incorrect headers and just extract the archive. As I
said, *Expand-Archive Powershell utility* on Windows can't extract the archive.
With 7zip 19.0 you can use *7z t archive_name* command, it will report the
incorrect headers.
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Bovykin updated COMPRESS-565:
Comment: was deleted
(was: ??Is the input.bin an empty file with size of 5GB???)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286987#comment-17286987
]
Evgeny Bovykin commented on COMPRESS-565:
-
??Is the input.bin an empty file with size of 5GB???
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-720) fix error about usage of DirectBuffer in jdk 16/17
[ https://issues.apache.org/jira/browse/IO-720?focusedWorklogId=554664=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554664 ] ASF GitHub Bot logged work on IO-720: - Author: ASF GitHub Bot Created on: 19/Feb/21 09:06 Start Date: 19/Feb/21 09:06 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #205: URL: https://github.com/apache/commons-io/pull/205#issuecomment-781939190 [](https://coveralls.io/builds/37268031) Coverage decreased (-0.02%) to 89.376% when pulling **ce51ecf60c78944e3001b770337156bfc3852cba on xenoamess-fork:clean_DirectBuffer** into **c54bf688e94b550c3ccd4c0789e0b3e00cf1d0ea on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554664) Time Spent: 40m (was: 0.5h) > fix error about usage of DirectBuffer in jdk 16/17 > -- > > Key: IO-720 > URL: https://issues.apache.org/jira/browse/IO-720 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > https://github.com/apache/commons-io/pull/205 > usage of DirectBuffer will cause IllegalAccessError. > This pr aims to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] coveralls commented on pull request #205: [IO-720] fix error about usage of DirectBuffer in jdk 16/17
coveralls commented on pull request #205: URL: https://github.com/apache/commons-io/pull/205#issuecomment-781939190 [](https://coveralls.io/builds/37268031) Coverage decreased (-0.02%) to 89.376% when pulling **ce51ecf60c78944e3001b770337156bfc3852cba on xenoamess-fork:clean_DirectBuffer** into **c54bf688e94b550c3ccd4c0789e0b3e00cf1d0ea on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (IMAGING-282) NullPointerException in org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata() when GraphicControlExtension is null
Samuel Monsarrat created IMAGING-282: Summary: NullPointerException in org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata() when GraphicControlExtension is null Key: IMAGING-282 URL: https://issues.apache.org/jira/browse/IMAGING-282 Project: Commons Imaging Issue Type: Bug Components: Format: GIF Affects Versions: 1.0-alpha2 Reporter: Samuel Monsarrat Attachments: problem.gif The attached gif file produces a NullPointerException in org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata() l553 due to variable id not having a GraphicControlExtension component (id.gce = null). This is set to null in findAllImageData l715. Elsewhere in org.apache.commons.imaging.formats.gif.GifImageParser is tested for null (l746). This gif seems to contain incorrect metadata. Simply re-saving it with ImageMagick correct the issue but since the gif is correctly displayed by all viewers at my disposal it would seem that org.apache.commons.imaging needs to be more permissive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IO-720) fix error about usage of DirectBuffer in jdk 16/17
[ https://issues.apache.org/jira/browse/IO-720?focusedWorklogId=554643=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554643 ] ASF GitHub Bot logged work on IO-720: - Author: ASF GitHub Bot Created on: 19/Feb/21 08:22 Start Date: 19/Feb/21 08:22 Worklog Time Spent: 10m Work Description: XenoAmess commented on pull request #205: URL: https://github.com/apache/commons-io/pull/205#issuecomment-781915793 @garydgregory @sebbASF please review. thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554643) Time Spent: 0.5h (was: 20m) > fix error about usage of DirectBuffer in jdk 16/17 > -- > > Key: IO-720 > URL: https://issues.apache.org/jira/browse/IO-720 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > https://github.com/apache/commons-io/pull/205 > usage of DirectBuffer will cause IllegalAccessError. > This pr aims to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] XenoAmess commented on pull request #205: [IO-720] fix error about usage of DirectBuffer in jdk 16/17
XenoAmess commented on pull request #205: URL: https://github.com/apache/commons-io/pull/205#issuecomment-781915793 @garydgregory @sebbASF please review. thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-720) fix error about usage of DirectBuffer in jdk 16/17
[ https://issues.apache.org/jira/browse/IO-720?focusedWorklogId=554642=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554642 ] ASF GitHub Bot logged work on IO-720: - Author: ASF GitHub Bot Created on: 19/Feb/21 08:21 Start Date: 19/Feb/21 08:21 Worklog Time Spent: 10m Work Description: XenoAmess commented on pull request #205: URL: https://github.com/apache/commons-io/pull/205#issuecomment-781915550 NOTICE: jdk 17 will still fail CI, but that is another problem to fix, and shall no in this pr. At least 16 should be OK now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554642) Remaining Estimate: 0h Time Spent: 20m (was: 10m) > fix error about usage of DirectBuffer in jdk 16/17 > -- > > Key: IO-720 > URL: https://issues.apache.org/jira/browse/IO-720 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > https://github.com/apache/commons-io/pull/205 > usage of DirectBuffer will cause IllegalAccessError. > This pr aims to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] XenoAmess commented on pull request #205: [IO-720] fix error about usage of DirectBuffer in jdk 16/17
XenoAmess commented on pull request #205: URL: https://github.com/apache/commons-io/pull/205#issuecomment-781915550 NOTICE: jdk 17 will still fail CI, but that is another problem to fix, and shall no in this pr. At least 16 should be OK now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (IO-720) fix error about usage of DirectBuffer in jdk 16/17
[ https://issues.apache.org/jira/browse/IO-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xu updated IO-720: -- Description: https://github.com/apache/commons-io/pull/205 usage of DirectBuffer will cause IllegalAccessError. This pr aims to fix it. was: usage of DirectBuffer will cause IllegalAccessError. This pr aims to fix it. Remaining Estimate: (was: 0h) > fix error about usage of DirectBuffer in jdk 16/17 > -- > > Key: IO-720 > URL: https://issues.apache.org/jira/browse/IO-720 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Major > Time Spent: 10m > > https://github.com/apache/commons-io/pull/205 > usage of DirectBuffer will cause IllegalAccessError. > This pr aims to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IO-720) fix error about usage of DirectBuffer in jdk 16/17
[ https://issues.apache.org/jira/browse/IO-720?focusedWorklogId=554639=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-554639 ] ASF GitHub Bot logged work on IO-720: - Author: ASF GitHub Bot Created on: 19/Feb/21 08:09 Start Date: 19/Feb/21 08:09 Worklog Time Spent: 10m Work Description: XenoAmess opened a new pull request #205: URL: https://github.com/apache/commons-io/pull/205 usage of DirectBuffer will cause IllegalAccessError. This pr aims to fix it. https://issues.apache.org/jira/browse/IO-720 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 554639) Remaining Estimate: 0h Time Spent: 10m > fix error about usage of DirectBuffer in jdk 16/17 > -- > > Key: IO-720 > URL: https://issues.apache.org/jira/browse/IO-720 > Project: Commons IO > Issue Type: Improvement >Reporter: Jin Xu >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > usage of DirectBuffer will cause IllegalAccessError. > This pr aims to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] XenoAmess opened a new pull request #205: [IO-720] fix error about usage of DirectBuffer in jdk 16/17
XenoAmess opened a new pull request #205: URL: https://github.com/apache/commons-io/pull/205 usage of DirectBuffer will cause IllegalAccessError. This pr aims to fix it. https://issues.apache.org/jira/browse/IO-720 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (IO-720) fix error about usage of DirectBuffer in jdk 16/17
Jin Xu created IO-720: - Summary: fix error about usage of DirectBuffer in jdk 16/17 Key: IO-720 URL: https://issues.apache.org/jira/browse/IO-720 Project: Commons IO Issue Type: Improvement Reporter: Jin Xu usage of DirectBuffer will cause IllegalAccessError. This pr aims to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
