[
https://issues.apache.org/jira/browse/COMPRESS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023582#comment-17023582
]
Stefan Bodewig commented on COMPRESS-502:
-----------------------------------------
I'm afraid the finalizer has there for a very long time and we can't simply
remove it.
Plugging in a logging framework would address the message going to System.err
but not address the two other shortcomings you mention.
In the case of Tika you probably want to make sure to never run the finalizer
which probably rules out a system property. This would leave us with yet
another constructor argument.
> Allow to disable closing files in the finalizer of ZipFile
> ----------------------------------------------------------
>
> Key: COMPRESS-502
> URL: https://issues.apache.org/jira/browse/COMPRESS-502
> Project: Commons Compress
> Issue Type: Improvement
> Components: Compressors
> Affects Versions: 1.19
> Reporter: Dominik Stadler
> Priority: Major
>
> Apache POI uses commons-compress for handling ZipFiles. We found that it
> sometimes does some auto-close magic in the finalizer of the ZipFile class
> with printing out to stderr, see
> https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=blob;f=src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java;h=23194560dace91d8052626f3bdc8f765f9c46d7e;hb=HEAD#l652.
>
> This has some shortcomings:
> * It prints to stderr which many large-scale applications try to avoid by
> using some logging framework, thus this output might "vanish" unseen in some
> installations or might cause unexpected side-effects
> * It prevents us from using tools for checking file leaks, e.g. we use
> [https://github.com/kohsuke/file-leak-detector/] heavily for analyzing
> test-runs for leaked file-handles, but commons-compress prevents this because
> it "hides" the unclosed file from this functionality
> * The behavior of automatic closing and reporting the problem is
> non-reproducible because it depends on finalizer/garbage-collection and thus
> any re-runs or unit-tests usually do not show the same behavior
>
> There are some fairly simple options to improve this:
> * Allow to disable this functionality via configuration/system-property/...
> * Make this "pluggable" so a logging-framework can be plugged-in or closing
> can be prevented for certain runs
>
> I can provide a simple patch if you state which approach you think would make
> most sense here.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
