Bug 40420 - gaps in logic of org.apache.jasper.compiler.Compiler.isOutDated()
Summary: gaps in logic of org.apache.jasper.compiler.Compiler.isOutDated()
Status: RESOLVED DUPLICATE of bug 33453
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 5.5.9
Hardware: All other
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-06 01:30 UTC by Vlad Ilyushchenko
Modified: 2006-09-05 18:46 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vlad Ilyushchenko 2006-09-06 01:30:31 UTC
Hi guys,

i've been meaning to report this problem quite a while ago but it is better late
then never... so here it goes:

We have a deployment system based on the back of Subversion, which facilitates
rolling application back as well as forward. The system also maintains file
dates to be consistent with the dates in the repository. 

We started noticing problems when Tomcat would choose not to compile JSPs that
have been updated. On the closer inspection it appears that isOutDated()
function would return as positive only if targetLastModified < jspLastModified,
which is not always the case when JSP files are rolled back in time.

I think it would be more accurate to compile the JSP if "targetLastModified !=
jspLastModified" and when the generated servlet and the compiled class have the
same "lastModified" value as the source JSP file. 

There is also more complicated problem to fix, which is to do with how "include"
files affect isOutDated() function. isOutDated() should be called recursively on
the included files instead of comparing their dates to the master jsp date.

I'd be happy to submit a patch should you want me to.

Regards,
Vlad
Comment 1 Mark Thomas 2006-09-06 01:46:27 UTC

*** This bug has been marked as a duplicate of 33453 ***