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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
