Dominik Drzewiecki wrote:
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
H1fmt 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
H1no 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
descriptionTagtest Application/description
display-nametagtest/display-name
welcome-file-list
welcome-fileindex.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 really hate when people post for bugs like this on tomcat-dev: they
cannot even be bothered to read the mailing list guidelines and post to
the right mailing list instead of either bugzilla or tomcat-dev.
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, g). 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
Try harder. If you cannot, then use a real operating system to work with.
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).
For user questions, try tomcat-user.
Rmy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
