[
https://issues.apache.org/jira/browse/COMPRESS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023640#comment-17023640
]
Dominik Stadler edited comment on COMPRESS-502 at 1/26/20 7:48 AM:
-------------------------------------------------------------------
We would like to use another tool to better report the actual location of where
the file was opened as the single output to stderr can be too less to find the
location of allocation in a fairly sized application.
So I mostly would like to not have "close()" be run as part of the finalizer.
The output to stderr is another shortcoming which might be unwanted for others.
A simple solution as far as I see would be to make it pluggable via a simple
static setter and use the current System.err.println as default.
E.g. something like the following (did not compile this, so might not fully
work this way):
{noformat}
private static Function<ZipFile> finalizeFun = (file) -> {
if (!closed) {
System.err.println("Cleaning up unclosed ZipFile for archive " +
archiveName);
file.close();
}
};
public static void setFinalizer(Function<ZipFile> fun) {
finalizeFun = fun;
}
protected void finalize() throws Throwable {
try {
finalizeRunnable->apply(this);
} finally {
super.finalize();
}
}
{noformat}
was (Author: [email protected]):
We would like to use another tool to better report the actual location of where
the file was opened as the single output to stderr can be too less to find the
location of allocation in a fairly sized application.
So I mostly would like to not have "close()" be run as part of the finalizer.
The output to stderr is another shortcoming which might be unwanted for others.
A simple solution as far as I see would be to make it pluggable via a simple
static setter and use the current System.err.println as default.
E.g. something like the following (did not compile this, so might not fully
work this way):
private static Function<ZipFile> finalizeFun = (file) -> {
if (!closed) {
System.err.println("Cleaning up unclosed ZipFile for archive " +
archiveName);
file.close();
}
};
public static void setFinalizer(Function<ZipFile> fun) {
finalizeFun = fun;
}
protected void finalize() throws Throwable {
try {
finalizeRunnable->apply(this);
} finally {
super.finalize();
}
}
> 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)
