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=15417.
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=15417
Add port for forced compilation of pages
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
Summary|jsp_precompile seems like a |Add port for forced
|possible DOS vulnerability |compilation of pages
--- Additional Comments From [EMAIL PROTECTED] 2002-12-17 07:09 ---
Ok but my requested enhancement still stands even if there is no DOS attack.
I did further direct testing of various timestamps/request combinations, and I
had begun to suspect that it was in fact as you described.
However as noted here, and in the end comment of bug 14165 version control
systems can provide updated versions of files with older time stamps. It
seems unreasonable that developers should have to maually (or with a script)
touch JSP pages just to view a coherent set of pages when moving between
branches, or from Trunk to Branch.
I am reopening with a new summary title because I am requesting a feature that
allows forced recompilation of pages for every load, preferably simply by
accessing them on a second port.
This is my rational for this suggestion stated another way:
As a developer I am quite willing to wait compilation time to see a page I am
testing correctly. Waiting for compilation is something we all acknowledge as
being part of the business. My suggetion provides a developer oriented
interface. A developer generally doesn't care how fast the page loads (within
reason). If it isn't loading the code he just wrote, or just checked out of
the repository, it is worse than useless, it is confusing.
One of the worst maifestations of this is that a Developer checks out the
branch B, edits foo.jsp and fixes a typo in bar.jsp. Then the next week the
developer needs to make changes to Branch A, which contains an older older
version of bar.jsp than B. The developer is editing barhelp.html in branch A
and wants to make links and add text relating to bar.jsp.
The problem is that since tomcat has cached bar.jsp when the developer was
working on B (last week) when he looks at bar.jsp in his browser he gets the
Branch B version of it even though he hasn't worked on branch B for a week. So
basing his changes on what he sees in his browser, the developer edits
barhelp.html, commits his changes, and as far as he can see all the links work
and all the wigits he mentions are there. Of course when it gets moved to a
new (read production) server, the cached pages have all been carefully cleared
as part of a release procedure or are empty because it is a fresh install,
suddenly barhelp.html turns out to have broken links to sections of bar.jsp
that don't exist in the A version and talk about wigits that only exist in the
B version.
An extreme example, perhaps, but the point is it is really quite confusing to
delete your entire directory, checkout a whole different branch, (perhaps even
restart tomcat for good measure), and find yourself looking at a mix of pages
from two different branches.
The newest version of each file among all branches you have ever worked on is
what you see when you browse around a devlopment server, unless you regularly
delete the contents of the work directory or give up on having sensible
modification dates and write a file touching script.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
