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]>
