[logback-dev] [JIRA] Commented: (LBCORE-127) Logback auto config closes the jar file previously opened in user code

[Ceki Gulcu (JIRA)]

    [ 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