[GitHub] commons-text issue #84: Update StringSubstitutor JavaDoc
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-text/pull/84 Thanks! ð --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-text pull request #84: Update StringSubstitutor JavaDoc
Github user asfgit closed the pull request at: https://github.com/apache/commons-text/pull/84 --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] close() and writing invalid streams
I'm for making it obvious and keeping clean ups localized, meaning add
try-with-resources blocks to all close() methods that need them.
Gary
On Thu, Jun 28, 2018 at 3:54 AM Stefan Bodewig wrote:
> Hi all
>
> https://issues.apache.org/jira/browse/COMPRESS-457 raises an issue that
> I vaguely recall we've talked about in the past but I may be wrong.
>
> Almost all our OutputStream close methods go along the lines of
>
> public void close() throws IOException {
> finishFormatSpecificStuff();
> closeUnderlyingStreamsOrChannelsAndOtherResources();
> }
>
> as some formats need to write trailers in order to create valid
> output. If for some reason finishFormatSpecificStuff() stuff fails the
> underlying stream will not be closed leading to a resource leak - unless
> you keep track of the underlying stream and close it yourself
> (try-with-resources probably).
>
> Do we want to do anything about this and if so what?
>
> We could modify all close implementations to perform resource cleanup in
> a finally block. Likewise we could add new (let's say unsafeClose())
> methods that only perform resource cleanup. Or we could properly
> document the behavior and ensure our examples contain resource cleanup
> code.
>
> I'm leaning toward "documenting" but want to ensure there are no leaks
> the user cannot prevent. For example DeflateCompressorOutputStream
> "end()"s the Deflater instance in a finally block while zip's
> StreamCompressor holds a reference to a Deflater that may never get
> closed.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
[LAZY][VOTE] Release Apache Commons Parent 47 based on RC1
We have fixed quite a few bugs and added some significant enhancements since Apache Commons Parent 46 was released, so I would like to release Apache Commons Parent 47. Apache Commons Parent 47 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1 (svn revision 27786) The Subversion tag for this RC is here: http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-47-RC1/ (svn revision XYZ2) N.B. the SVN revision is required because SVN tags are not immutable. Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1339/org/apache/commons/commons-parent/47/ These are the Maven artifacts and their hashes in Nexus: #Release SHA-1s #Thu Jun 28 09:10:16 EDT 2018 commons-parent-47-src-tar.gz=cee63ffe42ca49c9aac7ac5adb3b56224bb1e749 commons-parent-47-pom.asc=18c842fcce89df74d7e57b7c1ae8160f9e894a2a commons-parent-47-site-xml.asc=02a3017720627e8f4efe8e155ef6b5f23f79ed9d commons-parent-47-src-zip=fe9b1f12e52b9d3446910943191dc0eba82bbfd0 commons-parent-47-src-tar.gz.asc=8ed1fb05274158d1086fc1d98a525de664a83e02 commons-parent-47-site-xml=02b3b54d26d97a72fd55b20d027040ca0daf52b7 commons-parent-47-src-zip.asc=2d9aa20475a8635262a154462d713e66dc61ca42 #Release SHA-256s #Thu Jun 28 09:10:16 EDT 2018 commons-parent-47-src-tar.gz=41403ab20f8ab6b570eb663303e083422a53f1ace8ebf707bb70e7025da6080f commons-parent-47-pom.asc=33758c0525edac2301970de6644f397195d6f87b6e7c58ce51ead70e8b56d680 commons-parent-47-site-xml.asc=1431fb9c08f30e985885e2a149a33fb96c29a9181f15aa910892d2374134e581 commons-parent-47-src-zip=0752e9b2e046c057d71edb3ea196e8f7d36aae511c1d135d5f9cfb0a879be8b1 commons-parent-47-src-tar.gz.asc=fbee47f7e5d3689fcd888d16912106bd354028245f3d71ad9259027735be9dbf commons-parent-47-site-xml=29c8cdbab5859c506a8ce1b7a5d0fe63fabad15244ed79cde148eef0f9876246 commons-parent-47-src-zip.asc=a29f4169a938557ab13669c2769876f0862b104effa4e5b26bb5d80fcbd6c412 (no need for .asc hashes!) I have tested this with 'mvn clean install site' using: Maven home: /usr/local/Cellar/maven/3.5.4/libexec Java version: 1.8.0_162, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.13.5", arch: "x86_64", family: "mac" Details of changes since 46 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1/site (note some *relative* links are broken and the 47 directories are not yet created - these will be OK once the site is deployed.) RAT Report: https://dist.apache.org/repos/dist/dev/commons/commons-parent/47-RC1/site/rat-report.html KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Rob Tompkins, Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] close() and writing invalid streams
Hi all
https://issues.apache.org/jira/browse/COMPRESS-457 raises an issue that
I vaguely recall we've talked about in the past but I may be wrong.
Almost all our OutputStream close methods go along the lines of
public void close() throws IOException {
finishFormatSpecificStuff();
closeUnderlyingStreamsOrChannelsAndOtherResources();
}
as some formats need to write trailers in order to create valid
output. If for some reason finishFormatSpecificStuff() stuff fails the
underlying stream will not be closed leading to a resource leak - unless
you keep track of the underlying stream and close it yourself
(try-with-resources probably).
Do we want to do anything about this and if so what?
We could modify all close implementations to perform resource cleanup in
a finally block. Likewise we could add new (let's say unsafeClose())
methods that only perform resource cleanup. Or we could properly
document the behavior and ensure our examples contain resource cleanup
code.
I'm leaning toward "documenting" but want to ensure there are no leaks
the user cannot prevent. For example DeflateCompressorOutputStream
"end()"s the Deflater instance in a finally block while zip's
StreamCompressor holds a reference to a Deflater that may never get
closed.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
