tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominik Drzewiecki" <>
Subject Quite *different* behaviour of JDT compiler and ant compiler.
Date Tue, 14 Dec 2004 11:20:55 GMT
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.


<%@ taglib uri="" prefix="fmt" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <H1>fmt taglib</H1>
      <jsp:useBean id="now" class="java.util.Date"/>
      <fmt:formatDate value="${now}" type="both"/>   


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <H1>no fmt taglib</H1>
java.util.Date()) %>


<?xml version="1.0" encoding="ISO-8859-1"?>

<web-app xmlns=""
   <description>Tagtest Application</description>




<Context antiJARLocking="true">

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 
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).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message