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

Ceki Gulcu (JIRA) noreply-jira at qos.ch
Tue Dec 1 00:18:44 CET 2009


    [ http://jira.qos.ch/browse/LBCORE-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11390#action_11390 ] 

Ceki Gulcu commented on LBCORE-127:
-----------------------------------

I've added a test case based on this report. See [1]. In contrast to what you state, the pre-existing code in GenericConfigrator does the correct job. Invoking "urlConnection.setUseCaches(false)" instead of "urlConnection.setDefaultUseCaches(false);" makes the new test case fail.

So either I misunderstood your description and my new test case does *not* reproduce the case you are illustrating, or this entry is invalid.

[1] http://github.com/ceki/logback/commit/b018525e30ef54b8096d9c9cb9ae7db67eed1a6a

> 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

        


More information about the logback-dev mailing list