[
http://jira.qos.ch/browse/LBCORE-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11397#action_11397
]
Ceki Gulcu commented on LBCORE-127:
-----------------------------------
The URLConnection.setDefaultUseCaches instance method actually acts on a static
variable called 'defaultUseCaches which sets the default value of 'useCahces'
for subsequent connections. I have changed GenericConfigrator to invoke
URLConnection.settUseCaches(false) instead of
URLConnection.setDefaultUseCaches(false). This explains the unexpected
correlation between lbcore105() and lbcore127().
With this change this bug as *initially* reported is solved. However,
lbcore127() still fails, not on inputStream.read (the subject of the initial
report) but on jarFile.delete.
Indeed, if the file is opened in the cache mode, it is not closed even if the
close method is invoked. You need to open the other file with UseCaches set to
false.
Anyway, the problem is solved.
> Logback auto config closes the jar file previously opened in user code
> ----------------------------------------------------------------------
>
> Key: LBCORE-127
> URL: http://jira.qos.ch/browse/LBCORE-127
> Project: logback-core
> Issue Type: Bug
> Components: Joran
> Affects Versions: 0.9.17
> Reporter: tomliliu
> Assignee: Ceki Gulcu
> Priority: Blocker
>
> User code opens an input stream from a jar file first. Then logback auto
> config loads the configuration file from the same jar. User code will get the
> following exception when read the input stream later.
> {code title="Stack Trace"}
> java.util.zip.ZipException: ZipFile closed
> at java.util.zip.ZipFile.ensureOpenOrZipException(ZipFile.java:413)
> at java.util.zip.ZipFile.access$1100(ZipFile.java:29)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:445)
> at java.io.FilterInputStream.read(FilterInputStream.java:116)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
> at java.io.InputStreamReader.read(InputStreamReader.java:167)
> at java.io.BufferedReader.fill(BufferedReader.java:136)
> at java.io.BufferedReader.readLine(BufferedReader.java:299)
> at java.io.BufferedReader.readLine(BufferedReader.java:362)
> {code}
> {code title="Reproduce"}
> InputStream resourceAsStream =
> Thread.currentThread().getContextClassLoader().getResourceAsStream(logLocation);
> BufferedReader reader = new BufferedReader(new
> InputStreamReader(resourceAsStream));
> final Logger logger = LoggerFactory.getLogger(LogbackBugReproduce.class);
> logger.debug(reader.readLine());
> {code}
> It looks like in
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(URL url) method:
> urlConnection.setDefaultUseCaches(false);
> InputStream in = urlConnection.getInputStream();
> doConfigure(in);
> in.close();
> The input stream is associated with the same zip file instance of the users.
> Then close the input stream will close the zip file that user currently is
> using.
> After changing it to:
> urlConnection.setUseCaches(false);
> InputStream in = urlConnection.getInputStream();
> doConfigure(in);
> in.close();
> The input stream is associated with a different zip file instance. Then close
> the input stream will not affect the zip file used by the user code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://qos.ch/mailman/listinfo/logback-dev
