United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6449504 : REGRESSION:ZipException exception throws when try to read a XML file

Details
Type:
Bug
Submit Date:
2006-07-17
Status:
Resolved
Updated Date:
2010-05-05
Project Name:
JDK
Resolved Date:
2006-08-23
Component:
core-libs
OS:
windows_xp
Sub-Component:
java.net
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Duplicate:
Relates:

Sub Tasks

Description
J2SE Version (please include all output from java -version flag): 
 1.6.0-rc-b91

Does this problem occur on J2SE 1.4.x or 5.0.x ?  
  No, and does not happen in 1.6.0-rc-b76 

Operating System Configuration Information (be specific): 
  XP + SP2

Hardware Configuration Information (be specific): 
  Pentium 4, 3.00 GHz, 504 MB RAM.

Bug Description:
 Moved to the latest build (91) after working with build 76 and application stopped working: 
 It throws the following exception while trying to read a XML file:

java.util.zip.ZipException: ZipFile closed
	at java.util.zip.ZipFile.ensureOpenOrZipException(Unknown Source)
	at java.util.zip.ZipFile.access$1100(Unknown Source)
	at java.util.zip.ZipFile$ZipFileInputStream.read(Unknown Source)
	at java.util.zip.ZipFile$ZipFileInputStream.read(Unknown Source)
	at java.io.FilterInputStream.read(Unknown Source)
	at org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read(Unknown Source)
	at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
	at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
	at com.mercury.ftjadin.utils.xmlParsing.DomParserFactory.run(DomParserFactory.java:112) 


Steps to Reproduce (be specific):
  It happens when calling org.apache.xerces.parsers.DOMParser.parse for a XML
  file that is in a jar within the class path.
a sample application reproducing the bug had been added into the bug report.
The application works correctly on build 76 but fails on 91.
To use it, extract the attached zip, to c:\temp (you must use this hardcoded folder).
Then run the file c:\temp\mustandBug\run.bat

                                    

Comments
EVALUATION

note that user reported error is not using Sun software.  JAXP has package names of com.sun.org.apache.xerces.internal.  Apache versions of JAXP are being used in this CR.

some possible things that may be happening:
- user software is explicitly loading an Apache class v. using JAXP's Factory mechanisms
- user has Apache jars in endorsed dirs or bootclasspath with a META-INF entry that prefers Apache classes


one way to demonstate this would be to:
 
	java -verbose:class

and examine the output for classloading locations.  the classes will not be coming from Mustang.
                                     
2006-07-17
EVALUATION

note that this is not a JAXP bug, the calling trace is all Apache into J2S2.
the JAXP team will try and take a look at what is happening if a reproducible test case is provided.
                                     
2006-07-25
EVALUATION

I have taken the sample application provided and modified the run.bat script to use -verbose:class in the java command.  I am attaching the results (log) which show that no jaxp package names of com.sun.org.apache are being used.  I am changing the bug's category to hopefully find a more suitable fit based on the exception which is thrown.
                                     
2006-08-01
EVALUATION

This appears to be due the fix for 6212146.  I modified ZipFile.java to see opens and closes of ZipFiles, and found that sun.net.www.protocol.jar.URLJarFile.close is invoking ZipFile.close on an already-closed ZipFile.  The attached logjz06.txt shows the debug output and stack trace.  (The exception "who caused this" was thrown from ZipFile.close when an already-closed ZipFile was again closed.)

This regression does not occur in b77, but does in b78.  URLJarFile.java was changed in b78.  Undoing the change prevents this bug from occurring, hence the fix to 6212146 seems to have caused the regression.
                                     
2006-08-04
EVALUATION

The problem is the fix for 6212146 is closing the jar file whenever
it finds a JarURLConnection that points to a non-existing entry.
It should only do this when jar file caching is disabled.

Here is a minimised test case. Needs a jar file with one entry called
/test.txt

public class JarTest {

    public static void main (String[] args) throws Exception {

	URL url = new URL ("jar:file:foo.jar!/DoesNotExist.txt");
	JarURLConnection j1 = (JarURLConnection)url.openConnection();

	URL url2 = new URL ("jar:file:foo.jar!/test.txt");
	JarURLConnection j2 = (JarURLConnection)url2.openConnection();
	
	try {
	    j2.connect ();
	} catch (IOException e) {
	    System.out.println ("Got exception from j2; BAD");
	}

	try {
	    InputStream is = j1.getInputStream ();
	} catch (IOException e) {
	    System.out.println ("Got expected exception from j1 ");
	}

	try {
	    InputStream is = j2.getInputStream ();
	    readAndClose (is);
	    System.out.println ("OK");
	} catch (IOException e) {
	    System.out.println ("Got unexpected exception from j2");
	}
    }

    static void readAndClose (InputStream is) throws IOException {
	while (is.read() != -1) ;
 	is.close();
    }

}
                                     
2006-08-08



Hardware and Software, Engineered to Work Together