DO NOT REPLY [Bug 7059] New: - Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

[bu...@apache.org]

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=7059>.
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=7059

Jasper compiler holds pointers to jars in WEB-INF/lib: cannot delete

           Summary: Jasper compiler holds pointers to jars in WEB-INF/lib:
                    cannot delete
           Product: Tomcat 4
           Version: 4.0 Beta 1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Jasper
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: simran.gleason@sun.com


The jasper compiler is using JarURLConnections to open tag library jar files
in WEB-INF/lib. JarURLConnection caches the jar by default, and thus
a pointer to the jar (file descriptor?) is kept open so the jar cannot be
deleted. 

This makes redeployment and reloading of web apps difficult, because
taglib jars cannot successfully be replaced. On windows, the delete
operation fails. On Unix, the delete is successful, but the inode
sticks around, and the jar file remains cached. This means that the 
next compile of the JSP will use the old tag library rather than
the new one that was placed in WEB-INF/lib. 

A possible workaround might be to stop tomcat when taglib jars need
to change. 

However, from a development tool perspective, this isn't quite
satisfactory. For example, in netbeans webapp support, the 
jasper compiler is used to compile jsps to report errors without
having to run them. When jsps are compiled in web contexts that
have tag libraries in WEB-INF/lib, those tag libaries can no longer
be deleted. 

Looking in more detail at the jasper compiler, in two files:
org.apache.jasper.compiler.TagLibraryInfoImpl and
org.apache.jasper.compiler.TldLocationsCache, 
JarURLConnections are used, and there is a fixme comment about
the jar url connections caching the jars:
            // FIXME @@@
            // -- it seems that the JarURLConnection class caches JarFile 
            // objects for particular URLs, and there is no way to get 
            // it to release the cached entry, so
            // there's no way to redeploy from the same JAR file.  Wierd.

It turns out that there are two ways to prevent caching of the jar
files. One is to call setUsesCache(false) on each JarURLConnection
before calling getJarFile, e.g.:
            JarURLConnection conn =
                (JarURLConnection) url.openConnection();
	    conn.setUseCaches(false);
            jarFile = conn.getJarFile();

Another way is to call URLConnection.setDefaultUseCaches(false), 
which will change the default caching behaviour. Unfortunately, that
is not a static method (even though it sets a private static variable).
Also, it's kind of a large sledgehammer since it changes behaviour for 
all URLConnections. 

There may be other places as well where JarURLConnections are used on 
jars in WEB-INF/lib. They should all be setUseCaches(false)-ed.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>