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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2005-09-22 07:59 ------- (In reply to comment #9) > The .jsp file date stamp doesn't have to go back in time for the isOutDated > check to fail, it can and does fail in a more normal usage pattern. > Here is a scenario that shows the problem: > - I deploy version 1, the .jsp has time1 > - I make version 2 of the .jsp at time2 > - Visitor visits the site, and the .jsp is compiled at time3 > - I deploy version2 > - isOutDated returns false as time3 > time2 > > Would setting the date stamp of the .java and .class files to the date stamp > of > the .jsp file, and changing the comparison from < to != in the isOutDated > check > fix the problem sufficiently? Or are there negative side effects I haven't > thought of? > > I am working on patching my Tomcat to do exactly as above, I would be happy to > give it to someone for evaluation when its ready. As looked into in comment #6, this is not doable easily, which makes the few use cases which could benefit from this not worth it. Please try to read the report next time. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
