DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33453>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33453





------- Additional Comments From [EMAIL PROTECTED]  2005-09-23 00:32 -------
You disagree because you don't fully understand the problem.  If someone first
visits your .jsp after your modification, but before redeployment, you will be
hit by this bug.  You will wonder why your change didn't take effect.  It is not
necessary for the timestamp to move backwards.  You don't control when your .jsp
is accessed.  As your development/test servers will see different access than
your production, you will encounter a production bug that you didn't see in your
other environments.  Or if you are load balanced you will encounter the bug on
one machine but not another.  Good luck debugging that when it happens to you.

Using touch is not difficult, just add it to the documentation for JBoss and
every other web server that to hot deploy, do the following:  hot deploy, find
the tmp directory where the war is unpacked, touch every .jsp file that changed.
   And do that atomically so that noone can visit the .jsp inbetween.

The jasper code as is fails badly, my fix is trivial, is an improvement, but
still not 100% correct and has the side effect of changing a couple timestamps.
 The only place I'm aware of in Jasper that uses those timestamps is the broken
isOutDated logic.  

My fix doesn't handle dependencies correctly, and there is still the possibility
the .jsp is visited in the same second / minute / whatever the OS granularity is
as the modification.  Another side effect of my fix is that every .jsp will be
recompiled once after the fix is applied.

Timestamp rounding by the filesystem is not an issue, the timestamp of the .jsp
will be rounded the same way as the .class and .java files.  Every OS will round
timestamps in an internally consistent manner.

If changing the timestamps of the .java and .class files is still deemed
verboten, then I suggest copying the .jsp to the same temporary directory that
the .java and .class files are generated in, and preserving its timestamp.  Then
 timestamp, filesize, md5, even the exact contents of the file can be compared.

Remy, I am using JBoss4.0.2, how should I be deploying .jsps to production to
avoid this issue?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to