tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
Date Thu, 22 Sep 2005 23:01:07 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33453>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33453





------- Additional Comments From scottjoh@us.ibm.com  2005-09-23 01:01 -------
For what it's worth:
A few years ago we implemented the timestamp approach to this issue in the
WebSphere Application Server JSP container at the request of a small number of
customers - for whom it was critical.  A generated classfiles is set to the
timestamp of the source JSP file.  The classfile is considered to be outdated
when the two timestamps do not match.  File size is not part of the equation.
Tag files are handled the same way.
The timestamp disconnect :) of classfiles vs. their actual compilation time
rarely causes confusion among customers; it's a non-issue. We write compilation
time/date and other information into the generated .java file, in a comment, so
any confusion that might occur can be easily cleared up.
The timestamp != strategy has worked well on Versions 4 through 6, on all
platforms. Dependency tracking (static includes, TLDs, tag files) is easily
managed. The race condition described in bug 23406 has never been reported. 
Timestamp rounding has never been an issue.
Google for "websphere jsp timestamp" and you'll find some info about the
implementation.
Some things to consider if you all decide it's an appropriate change for Tomcat
(this stuff is all documented and easily found on the web):
When serving JSP sources from JARs, we use the timestamp of the JAR for the
outdated check.
Any expansion of WARs or other compressed artifacts with precompiled JSP classes
must maintain timestamps (doh).
There *will* be first-time recompilation cost to Tomcat users if this is
implemented, as Jonathan mentioned.  Some won't like it.  
Keeping data only in a runtime artifact like the servletwrapper won't work, as
Remy stated.
  



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message