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-23 00:13 -------
(In reply to comment #21)
> 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?

Nope, people can restart the container.

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

Arg MD5.

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

This is simple, and maybe acceptable, but would make the cost of checking for
recompilation (even) more expensive than it is right now.

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

On access compilation and its friend the development mode - which you are using
or you would not have this "issue" - should not be used in production (the only
reason why it is not as bad as it used to be is that I tweaked it do do only one
check at most per page per time interval - obviously if there are 100 pages, my
trick will not work that well).

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

Reply via email to