tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 3644] - Errors reloading resources from jars: possible JDK bug
Date Tue, 18 Sep 2001 09:46:26 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3644>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3644





------- Additional Comments From bojan@binarix.com  2001-09-18 02:46 -------
Attaching the bug report to Sun and a source code used to replicate the problem
(just a straight app, no servlet container necessary).

---------------------------------------------------------------------------


This bug seems to be similar to bugs 4040920 and 4103650, which, a far
as I can tell, some people still reported in 1.3.

I can replicate the problem every single time, so I'll submit the code
that I used.

This is my little test program:

------------------------------------------------------
/*
 * @(#)ZipFileTest.java
 *
 * This software is licensed under GNU General Public License
 * http://www.gnu.org/copyleft/gpl.html
 *
 */

import java.io.*;
import java.net.*;
import java.util.*;

class ZipFileTest extends ClassLoader{

  public static void main(String argv[]){
    LineNumberReader in=new LineNumberReader(new
InputStreamReader(System.in));

    while(true){
      Properties p=new Properties();
      try{
        // Get the resource using the first ClassLoader object (first
set)
        ZipFileTest t=new ZipFileTest();
        System.err.println("t="+t);

        InputStream
i=t.getResourceAsStream("com/binarix/velocity/application.properties");
        System.err.println("i="+i);
        p.load(i);
        p.save(System.out,"");

        // Get rid of the objects
        i=null; t=null; p=null;

        // Wait for user input while replacing the jar
        in.readLine();
      } catch(Throwable t){
        System.out.println(t);
        t.printStackTrace(System.out);
        System.exit(1);
      }
    }
  }
}
------------------------------------------------------

As you can see, it's not much to look at. It loops indefinitely until
something bad happens. Anyway...

I run the program like this:

------------------------------------------------------
java -cp
/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar:/home/groups/devel/apps/zipfile-test:$CLASSPATH
ZipFileTest
------------------------------------------------------

You'll notice a little app.jar at the beginning of the classpath. It
looks like this:

------------------------------------------------------
jar tvf /home/httpd/html/binarix.dev/WEB-INF/lib/app.jar 
     0 Tue Sep 18 18:43:34 EST 2001 META-INF/
     0 Tue Sep 18 17:56:30 EST 2001 com/
     0 Tue Sep 18 17:56:30 EST 2001 com/binarix/
     0 Tue Sep 18 17:56:30 EST 2001 com/binarix/wpm/
     0 Tue Sep 18 18:43:34 EST 2001 com/binarix/velocity/
   598 Tue Sep 18 17:56:30 EST 2001 com/binarix/wpm/ParseXML.class
  3868 Tue Sep 18 17:56:30 EST 2001 com/binarix/wpm/ParsePage.class
  6129 Tue Sep 18 17:56:30 EST 2001
com/binarix/velocity/velocity.properties
   133 Tue Sep 18 17:56:30 EST 2001
com/binarix/velocity/beans.properties
 14012 Tue Sep 18 18:43:34 EST 2001
com/binarix/velocity/PumpServlet.class
   880 Tue Sep 18 17:56:30 EST 2001
com/binarix/velocity/application.properties
    43 Tue Sep 18 18:43:34 EST 2001 META-INF/MANIFEST.MF
------------------------------------------------------

This is (accidentally) an application that I give Tomcat to chew. All
we're interested in here is the properties file application.properties.

First time around, this is the output of the program:

------------------------------------------------------
t=ZipFileTest@1fef6f
i=java.util.zip.ZipFile$1@1fbe93
#
#Tue Sep 18 19:16:28 EST 2001
logfile=/var/tomcat/logs/binarix.dev-dnsearch.log
whois=http\://www.networksolutions.com/cgi-bin/whois/whois?STRING\=
register.feedback=info@binarix.com
jnp-port=1099
inquiry.validate=name,title,company,phone,fax,email
dbms=postgresql
user=binarix
register.mailfields=domain,name,title,company,address,city,state,postcode,country,phone,fax,email,businessname,businessnumber,regstate,austcompanyname,abn,comments
inquiry.mailfields=name,title,company,phone,fax,email,comments
whoisau=http\://www.aunic.net/cgi-bin/aunicstatus.pl?html-form\=yes&amp;action\=Domain+Name+Lookup&amp;domain-name\=
inquiry.feedback=info@binarix.com
application=binarix
register.validate=name,title,company,address,city,state,country,phone,email
database=binarix
password=****************
jnp-host=localhost
driver=org.postgresql.Driver
------------------------------------------------------

So, the properties are properly read from the file and written out to
standard output.

While waiting for input (in.readLine()), I build another app.jar and
replace the original file. Only PumpServlet.class is actually changed.
No other files are changed in any way. This is what happens:

------------------------------------------------------
t=ZipFileTest@712c4e
i=java.util.zip.ZipFile$1@13dee9
java.util.zip.ZipException: invalid distance code
java.util.zip.ZipException: invalid distance code
        at
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:139)
        at java.io.FilterInputStream.read(FilterInputStream.java:93)
        at java.io.InputStreamReader.fill(InputStreamReader.java:173)
        at java.io.InputStreamReader.read(InputStreamReader.java:249)
        at java.io.BufferedReader.fill(BufferedReader.java:139)
        at java.io.BufferedReader.readLine(BufferedReader.java:299)
        at java.io.BufferedReader.readLine(BufferedReader.java:362)
        at java.util.Properties.load(Properties.java:192)
        at ZipFileTest.main(ZipFileTest.java:26)
------------------------------------------------------

Note here that I have brand new ZipFileTest (ClassLoader) and ZipFile$1
objects, so we should 'start over'. But, it doesn't happen. The old
stuff is 'cached' somewhere, somehow and the whole thing blows up.

If I run the program again (ie. new instance of the VM) with the file
used the second time around, everything is back to normal, as long as
the underlying file is not switched.

If you wish to test this further, I can send you the jar file I'm using
for testing.

This bug is preventing proper class reloading in Tomcat 3.3 and 4 (to my
best knowledge only on Windows), since it depends on ZipFile to work
correctly.

If class files and other resources are used directly (ie. not through
the jar file) everything is working just fine. Actually I have 10+ web
applications that are reloading themselves and associated resources (in
my case properties files) if files are not packed in jars, but rather
stored as straight files.

Mime
View raw message