|Summary:||Jasper doesn't recompile a JSP if it was modified while being compiled|
|Product:||Tomcat 9||Reporter:||Karl von Randow <karl>|
|Component:||Jasper||Assignee:||Tomcat Developers Mailing List <dev>|
Description Karl von Randow 2019-10-31 21:10:28 UTC
Created attachment 36867 [details] Compiler patch In our development workflow we often save a JSP and reload it in the browser, again and again. If we happen to save a JSP while Jasper is compiling it, Jasper will assign the timestamp of the modified JSP to the generated java and class files even though they were in fact generated from the previous version of the JSP, as Jasper reads the JSP's modification time _after_ compiling. Jasper will then not detect that the change was made and will not recompile the JSP again until the next time it is modified. The fix is to simply move the line of code in org.apache.jasper.compiler.Compiler in the compile(boolean, boolean) method that reads the jspLastModified from after the compile to before it. This change will mean no missed JSP updates. A simple patch is attached.
Comment 1 Christopher Schultz 2019-11-01 13:55:26 UTC
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.
Comment 2 Mark Thomas 2019-11-04 15:27:03 UTC
Patch looks good to me. Many thanks. Fixed in: - master for 9.0.28 onwards - 8.5.x for 8.5.48 onwards - 7.0.x for 7.0.98 onwards
Comment 3 Karl von Randow 2019-11-05 01:40:56 UTC
Thank you very much. Love your work.