https://bz.apache.org/bugzilla/show_bug.cgi?id=63897
Christopher Schultz <ch...@christopherschultz.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |PatchAvailable
--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> ---
Many thanks for your analysis and your patch.
Based solely upon the description and not having read the code, I tend to agree
that the timestamp used for comparison against the source JSP needs to be the
timestamp of the source JSP as it was being initially read for compilation.
I think the only place that is stored is in the timestamp of the generated
.java/.class files themselves, and there is not any other repository of that
metadata. Some filesystems (any modern ones?) don't have great time-resolution
and that may also be a contributing factor.
As this is a bit of an edge case -- nobody should be modifying JSP files at
high-frequency in production -- I don't think it makes sense to consider any
separate repository of such metadata.
(I can say for sure that I've had timing issues with Tomcat for years that are
similar to this -- usually with regard to reloading the whole container -- and
I wonder if this bug is representative of a class of problems like this.)
This patch LGTM, but I want to let others weigh-in just in case there is some
specific reasoning behind the timing of the file-timestamp-capture.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
