Compiled .class file timestamps do not match .jsp timestamps, causing JSP precompilation to add no benefit in Tomcat 7

• Type: Regression Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 6.1.0 CE RC1
• Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1
• Component/s: Infrastructure > App Servers
• Labels: None
• Similar Issues: Show 5 results ; ;

  LPS-24991	Precompilation is ineffective because DirectServletRegistry changes timestamps on JSPs
  LPS-9420	JSP compile failures - during precompile
  LPS-30433	Recreated Asset Entries contain different createdDate and modifiedDate timestamps instead of the actual asset timestamps
  LPS-14215	During JSP precompile, add JARs to the classpath rather than unzip them into a common folder
  LPS-11630	Wrong file modified timestamp after portlet hot deployment so JSPs are not recompiled

Between Tomcat 6 and Tomcat 7, JSP compilation was updated to allow older JSP files to replace newer JSP files and trigger a recompilation. To do this, the timestamp checking was changed from a lenient check where as long as the .class file is newer than the .jsp file it's treated as up-to-date to a strict check where the .java and .class files will be given the same modified timestamp as the .jsp file.

As a result of this change, build-time JSP precompilation is adding no performance benefit because the .class files currently have a last modified timestamp of the time when they were generated. This means that Tomcat's modified timestamp check fails and Tomcat will try to regenerate the .java and .class files.

To fix this, we'll need to ensure that the timestamp of .class files are the same as the .java and .jsp files when we precompile for Tomcat 7 and above.