Description of problem:
Create a jbosseap-6 app, custom the jsp file in repo and git push. the custom jsp page could show correctly in web.
Then change the jsp file again in repo and git push, the change won't take effect when access the app in web.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a jbosseap-6 app
2. create a new page under src/main/webapp/ dir with the following code:
<% out.println("version 1"); %>
4. push the change
5. check the $app-url/testpage.jsp page to see if the change takes effect (print "version 1")
6. change the testpage.jsp again
eg: change version 1 to version 2
<% out.println("version version 2"); %>
7. git push
8. access the app in web $app-url/testpage.jsp
9. restart the app and access the app again
always got version 1 in step8-9
show version 2 in step8
issue can't be reproduced for jbossas7 app
The issue appears to be in jboss jsp caching. The compiled testpage.jsp file ends up cached here:
with the current time from the openshift node.
meanwhile, the actual jsp is stored here with the time from the openshift client machine:
In this case, the openshift node has a significantly advanced clock. As a result, jboss sees the timestamp of the jsp as being older than the latest cached compiled classes (again, stored in:
and so it does not update the cached copy with the contents in /var/lib/openshift/53cebc02186355494c00004e/jbosseap/standalone/tmp/vfs/temp/tempd56ce3f88d7750b9/ROOT.war-937230a5bc488ab6/testpage.jsp
For some reason on jbossAS, the timestamp in /var/lib/openshift/53cebc02186355494c00004e/jbosseap/standalone/tmp/vfs reflects the time on the openshift node, so this problem does not occur.
The simple solution would be to wipe out the tmp directory as part of deploy, though this would have negative performance implications since cached classes that have not changed would be lost.
Otherwise I need to speak w/ the jboss team to understand this behavior.
*** Bug 1199301 has been marked as a duplicate of this bug. ***