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 [EMAIL PROTECTED] 2005-09-22 23:43 ------- Setting timestamp seems not a clean solution to me. API doc says, hat the time might be rounded, so even if we try to set the time to the same timestamp we get from the JSP, the resulting timestamp might differ and not be equal to the original time (Consider diffrent file system types etc.). I would also prefer a solution where information about the JSP is saved and later compared. Would JspServletWrapper be the right place to save the original JSP modification time? MD5 would be nice, but then md5 checksum would need to be recalculated on every JSP check with unchanged file time, so unfortunately not a rare case. I guess that's too bad for performance. Maybe timestamp and size would be enough, because both can be retrieved easy and efficiently, and if timestamp did not change, but content did change, it is very likely, that the file was in progress of being written to, so at least size should have changed. If we agree, that it's worth trying to make a patch to JspServletWrapper, I'll try to submit one tomorrow (not really for 5.5.12). One thing remains though: I'm not sure how to handle the case of included JSPs (dependecies). Maybe I'll find a solution by digging deeper into Jasper. One last word: I had customers having problems with both scenarios: rolling back file changes, but also distributing content with wrong timestamps (future time) and in consequence continuous recompilation for several minutes. Not trying to assume a simple time model seems to make jasper more robust. -- 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]
