Since I believe that there *still* is some major flaw in the jsp compiler I prepared a sample application. The application consists of two jsp pages: the one that is using taglibs (namely jstl) and the one that is not. Context.xml is crafted so that it should prevent so called JAR locking/resource locking.
notags.jsp <%@ taglib uri="http://java.sun.com/jsp/jstl/fmt"; prefix="fmt" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <body> <H1>fmt taglib</H1> <jsp:useBean id="now" class="java.util.Date"/> <fmt:formatDate value="${now}" type="both"/> </body> </html> tags.jsp <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <body> <H1>no fmt taglib</H1> <%=java.text.DateFormat.getDateTimeInstance().format(new java.util.Date()) %> </body> </html> WEB-INF/web.xml <?xml version="1.0" encoding="ISO-8859-1"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4"> <description>Tagtest Application</description> <display-name>tagtest</display-name> <welcome-file-list> <welcome-file>index.html</welcome-file> </welcome-file-list> </web-app> META-INF/context.xml <Context antiJARLocking="true"> </Context> There are also jstl.jar and standard.jar below WEB-INF/lib With such an application I have conducted two types of tests: 1. with an out-of-the-box jdt-compiler 2. with an old-style ant-compiler. (I substituted jdt as follows: removed jasper-compiler-jdt.jar, copied ant.jar and ant-launcher.jar from tomcat 5.0.30 distro to common/lib, copied tools.jar from java 5.0 sdk to common/lib. No changes in default web.xml) Each test consisted of the following steps: 1. Clean tomcat startup 2. ant deploy 3. access http://localhost:8080/tagtest/notags.jsp (this invokes the jsp compilation) 4. ant undeploy 5. ant list, check webapp dir to see if there is anything left in the context dir 6. ant deploy 7. access http://localhost:8080/tagtest/tags.jsp (this invokes the jsp compilation with the dependant taglib) 8. ant undeploy 9. ant list, check webapp dir to see if there is anything left in the context dir And now (drumroll...) the conclusions: When using the old ant-compiler (notice that the fork is set to false) all nine steps of the test pass. After the ninth one (the successfull undeployment) there is nothing left (no context dir in the webapp directory). After switching back to the JDT compiler, thought the undeploy task completes with the OK status, there is the taglib (tagtest/WEB-INF/lib/standard.jar) left. This doesn't happen (with either compiler) if the application beeing deployed is precompiled, of course. This leads (me) to the conclusion that JDT screws things up. I am not reopening a bug report, as I do not want to get cursed by Remy ;). I have been struggling with this problem for quite some time with an application I currently develop. It really makes the deployment cycle tiresome (I have to restart tomcat, grrrr). And the antiJARLocking neither antiResourceLocking solution seems to work - I have tried several combinations: antiJARLocking="true" on context.xml, antiResourceLocking="true" on context.xml, antiJARLocking="true" on default context.xml and antiResourceLocking="true" on default context.xml The test setup was: W2K/WXP, Tomcat 5.5.6 (ant compiler jars taken from Tomcat 5.0.30), Java 5.0 SDK If anyone cares, I can provide the test application used for described tests containing an ant build/deployment script (slightly modified build.xml from the deployer package). cheers, /dd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
