DO NOT REPLY [Bug 33453] Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #69 from Mark Thomas  2011-06-20 18:03:09 UTC ---
This has been fixed in 7.0.x and will be included in 7.0.17 onwards.

The fix was fairly invasive so it will not be back-ported to 6.0.x or 5.5.x.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 33453] Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

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

--- Comment #68 from Mark Thomas  2011-05-28 18:55:51 UTC ---
Feedback on proposed TC7 patch:
http://tomcat.markmail.org/thread/mbjdpr4bvw6gzx62

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 33453] Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

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

--- Comment #67 from Mark Thomas  2011-05-20 16:26:13 UTC ---
Created attachment 27040
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=27040
Proposed patch for Tomcat 7

Having spent a little time on this, I am attaching a proposed patch for Tomcat
7. The patch breaks binary compatibility for compiled JSPs which I am not at
all comfortable about. I have some ideas for a solution to that which I will be
discussing on the dev list.

If this issue is addressed in Tomcat 7, I don't see the fix being back-ported
to earlier versions.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 33453] Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

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

Antoine Prevosto  changed:

   What|Removed |Added

 CC||antoine.prevo...@gmail.com

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 33453] Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 CC||gus.h...@olin.edu

--- Comment #66 from Mark Thomas  2010-12-17 09:14:37 EST ---
*** Bug 15417 has been marked as a duplicate of this bug. ***

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 33453] Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

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


Roberto <[EMAIL PROTECTED]> changed:

   What|Removed |Added

Version|5.5.9   |5.5.15




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

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

DO NOT REPLY [Bug 33453] Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

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





--- Comment #65 from Luis Naver <[EMAIL PROTECTED]>  2008-08-11 14:00:43 PST ---
I just got bit by this bug and lost a good part of my day trying to locate it. 
I have tomcat on my development machine (winXP) configured to UTC and the
machine itself is set for PST. 

Here's the procedure

 * make a change to my source jsp
 * war it up
 * stop tomcat
 * delete the existing war and webapps folder
 * copy the new war into the webapps dir
 * start tomcat

The problem:
Tomcat will expand the war however the last modified date on the jsp file will
be adjusted (incorrectly?) to 8 hrs earlier.  As the previous change was
compiled less than 8hrs ago the jsp is not recompiled and the outdated .java
and .class files remain in the work\Catalina\localhost directory.  The result
is my changes are not reflected.

For now I will delete the work directory at the same time I delete the old war
file.  This way at least, as a developer, I know that what tomcat is serving is
my most recent code.


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

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

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-12-28 06:42 ---
I haven't had to make any additional changes to the code in the patch.  I have 
only used the patch in conjunction with JBoss 4.0.2.  I have been using the 
code in development and production since I posted it.

(In reply to comment #63)
> (In reply to comment #62)
> Darryl's last comments aside on changing the management of the entire work 
tree,
> I want to ask Jonathan and anyone who's used his patches: have they been 
stable
> and OK?  Have there been any modifications needed to them?  If not, i.e. if
> they've been stable, I'm tempted to add them to the 5.5 tree.



-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|P1  |P3
Version|Nightly Build   |5.5.9




-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-12-26 17:13 ---
(In reply to comment #62)
Darryl's last comments aside on changing the management of the entire work tree,
I want to ask Jonathan and anyone who's used his patches: have they been stable
and OK?  Have there been any modifications needed to them?  If not, i.e. if
they've been stable, I'm tempted to add them to the 5.5 tree.



-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-09-08 15:43 ---
My patch doesn't change the overall strategy for invoking the isOutDated() 
check, as you are suggesting. The isOutDated() check does load the class, as 
it did prior to my patch. Revalidating the entire tree would cause all the 
class files to be loaded, which would be bad. However, with the isOutDated() 
method fixed, I see no reason to revalidate the entire tree. 

(In reply to comment #61)
> What are the side-effects of revalidating the entire tree ?  Does it cause 
all
> class files to be loaded or can the revalidation occur without having any
> lasting overheads (like increased memory consumption and slower revalidation
> process due to parsing of more complex .class data).
> My method only seeks to delete stale work/ .java and .class files during web-
app
> deployment.
> It does not seek to recreate and load them, that can be left to moment of 
first
> use (although it would natually lead on to facilitating an automatic 
recreation
>  function).
> By opening the .java file and looking for a magic comment and closing the 
file
> again, there is no lasting overhead.  Since we never loaded the class.  
Which is
> just great for a revalidation pass during deployment.
> I'm a believer there should be a configuration mode of TC which is 
watertight,
> such that no amount of abuse will make the things fail in a way that bites 
you.
>  The work/ directory is a nice speedup but the implementation is more a hack
> than an optimization, since it clearly breaks down in situations you wouldn't
> expect.
> This bug/problem hits developers a lot more than production upgrades.



-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-09-08 05:29 ---
What are the side-effects of revalidating the entire tree ?  Does it cause all
class files to be loaded or can the revalidation occur without having any
lasting overheads (like increased memory consumption and slower revalidation
process due to parsing of more complex .class data).

My method only seeks to delete stale work/ .java and .class files during web-app
deployment.

It does not seek to recreate and load them, that can be left to moment of first
use (although it would natually lead on to facilitating an automatic recreation
 function).

By opening the .java file and looking for a magic comment and closing the file
again, there is no lasting overhead.  Since we never loaded the class.  Which is
just great for a revalidation pass during deployment.

I'm a believer there should be a configuration mode of TC which is watertight,
such that no amount of abuse will make the things fail in a way that bites you.
 The work/ directory is a nice speedup but the implementation is more a hack
than an optimization, since it clearly breaks down in situations you wouldn't
expect.

This bug/problem hits developers a lot more than production upgrades.

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-09-07 15:18 ---
Daryl,  see comments #35 - #45 and the 4 patch files I posted in the 
Attachment section.  The patch I submitted in March completely fixes this 
problem in a manner similar to your suggestion.

The patch works by storing the timestamp of the .jsp and all its 
dependent .jsps as member data in the compiled servlet.  The isOutDated() 
method was modified to compare the timestamp of the .jsp against the added 
timestamps using != instead of >.

(In reply to comment #59)
> It would be nice to have re-validation maybe that could be implemented using
> magic .java file comments in the japser output "// Jasper-JSP-Prerequisite:
> foobar/test.jsp 72383828372000" where both the top level source and all 
included
> fragments are listed with their Epoch millis for timestamp.  Then the process
> would be to recurse the work/org/apache/ tree, reading all the .java and
> performing a simple stat() on the source files.  This could be done in the
> background with live requests taking priority to be checked on first access
> after deployment.


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-09-07 05:54 ---
(In reply to comment #55)
> I believe Jasper really should remove cached JSP's from the work directory 
> when
> an app is undeployed (or redeployed). I think this is common, important, and
> quite different than the rather obscure case of rolling back an older version
> from version control. This would also avoid a performance hit in checking out 
> of
> date on JSP's and wouldn't surprise people (I wouldn't expect JSP's to be 
> cached
> after redeploying an app, indeed I think it's surprising behavior!)

This is a very good point that I would agree with.  It is not upto any external
tools to effectively manage the "work/" directory for Tomcat.  This directory
should be self-managing and be implemented on the side of caution, the caching
of JSP pages is a benifit not a right.

I think the following new rule would work:
 * The work/ directory is only cleaned of unused contexts when a web-app is
undeployed (while the container is running, aka hot-undeploy) or found to no
longer exist after all configuration parsing has been done at container startup.

Although it is somewhat difficult to manage web-app upgrades taking place when
the container is shutdown.  Which I'd say was a pretty common event.

One way around that situation would be to detect a web-app update has taken
place.  The simplest for TC (and the sys-admin) way I can think of, is for TC to
remember the exact timestamp on the WEB-INF/web.xml file which the pre-compiled
pages relate to.  Make it create an empty file and touch up the timestamp to
match the real web.xml as work/web.xml.timestamp.

The sys-admin must then only touch the WEB-INF/web.xml (when he upgrades his
web-app while the container is stopped).  When TC boots up again it detects the
timestamp is not equal and presumes the web-app was changed also, this causes a
flush of the work/ for that context.

The idea being this approach would be a whole lot simpler than re-validating the
entire work/ cache from the source JSPs during all webapp deployments.


It would be nice to have re-validation maybe that could be implemented using
magic .java file comments in the japser output "// Jasper-JSP-Prerequisite:
foobar/test.jsp 72383828372000" where both the top level source and all included
fragments are listed with their Epoch millis for timestamp.  Then the process
would be to recurse the work/org/apache/ tree, reading all the .java and
performing a simple stat() on the source files.  This could be done in the
background with live requests taking priority to be checked on first access
after deployment.

When work/* file that have been sucessfully revalidated (or deleted/recreated)
have their timestamp updated, so that it is possible for any thread to know if a
re-validation is required on a page, since the timestamp will be older than the
deployment time of the web-app context.

This would have no longterm JVM impact that loading classes might have, we can
put what we like in the .java file and access it easily.


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-09-07 00:18 ---
Our app needs to be portable to a variety of Servlet containers (and for
different versions), so we can't precompile for any one server.

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-09-07 00:11 ---
Why not just distribute your app with pre-compilied JSPs and avoid all these
problems?

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-09-06 23:59 ---
For the next release of your software, I would register an error handler that 
catches this error, and sends an email with the contents to the tomcat-dev 
mailing list.

(In reply to comment #55)
> if someone downloads 1.0 after you released 1.1 they can expect a lot of 500
> errors from NoSuchMethodError)



-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-09-06 23:51 ---
I think this is a significant problem when you really have different
organizations building and deploying, e.g., for publicly distributed
applications. A common timeline would be:
January - release 1.0 of app
March - JSP in app is updated
April - release 1.1 of app frozen for QA
May - user downloads and installs 1.0 
June - user downloads and installs 1.1

In this case, Jasper will view the compiled date of the 1.0 JSP as May and view
it as newer than the change date of the 1.1 JSP. I gather that the "best
practice" for building a web app for use with Tomcat would be to touch all the
JSP's in your web app in your release process so you minimize the risk (although
if someone downloads 1.0 after you released 1.1 they can expect a lot of 500
errors from NoSuchMethodError)

I believe Jasper really should remove cached JSP's from the work directory when
an app is undeployed (or redeployed). I think this is common, important, and
quite different than the rather obscure case of rolling back an older version
from version control. This would also avoid a performance hit in checking out of
date on JSP's and wouldn't surprise people (I wouldn't expect JSP's to be cached
after redeploying an app, indeed I think it's surprising behavior!)

One of the users of our Web app just hit this issue today:
http://www.glassbox.com/forum/forum/addpost?parent=235 and with a little
googling you can see others e.g.,
http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL 
PROTECTED]



-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2006-09-06 01:46 ---
*** Bug 40420 has been marked as a duplicate of this bug. ***

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-05-11 20:38 ---
(In reply to comment #51)

> I've fixed it, getting the fix incorporated into the codebase appears to be 
> the
> impossible part.  Feel free to use the code from my patch and give feedback if
> you find any problems.

I just wasted a embarrasing amount of time trying to figure out why one of our
developers was having problems seeing her changes 'live' on the test machine
after changing a JSP file.  I'd assumed that since I had Tomcat running in
Development mode, it was going to recompile the page when it changed 

I'm glad to see that the seriousness of this bug has been recognized, and a
patch developed... even if it doesn't seem to have the blessing of some of the
developers.  The patch certainly saved me a lot of hassle.  Thanks!!

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-05-06 14:04 ---
(In reply to comment #51)
> I've fixed it, getting the fix incorporated into the codebase appears to be 
> the
> impossible part.  Feel free to use the code from my patch and give feedback if
> you find any problems.

Thanks, but it seems we will be migrating to JBoss 4.0.4 when the GA version
comes out and it shouldn't be an issue anymore. I'm fortunate enough I don't
have to use Tomcat standalone.

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-05-03 21:00 ---
(In reply to comment #50)
> > The problem isn't isolated to an "edge" case, it affects the standard way 
> > apps
> > are deployed.  Thus the numerous other people who have encountered it. 
> 
> I certainly agree. I encountered this issue multiple times. I took quite some
> time and flustration to discover this bug. 
> The workaround I currently use is deploying exploded .war contents and setting
> scp not to preserve timestamps, effectively forcing all copied JSP files to be
> recompiled.
> I think the bug is obviously serious and is definately not isolated to an 
> "edge"
> case. 
> I'm glad someone is trying to fix it.

I've fixed it, getting the fix incorporated into the codebase appears to be the
impossible part.  Feel free to use the code from my patch and give feedback if
you find any problems.

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-05-03 20:54 ---
> The problem isn't isolated to an "edge" case, it affects the standard way apps
> are deployed.  Thus the numerous other people who have encountered it. 

I certainly agree. I encountered this issue multiple times. I took quite some
time and flustration to discover this bug. 
The workaround I currently use is deploying exploded .war contents and setting
scp not to preserve timestamps, effectively forcing all copied JSP files to be
recompiled.
I think the bug is obviously serious and is definately not isolated to an "edge"
case. 
I'm glad someone is trying to fix it.

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-04-28 14:05 ---
(In reply to comment #48)
> As I said earlier, I don't think fixing the edge cases is worth adding the
> related complexity. It's very simple. As for JBoss "fixing" it, Tomcat "fixes"
> it too: you simply need to undeploy/redeploy webapps, and/or add some listener
> to clean up the work directory, which is trivial to do. If that's all you want
> to achieve, why did you focus on a complex patch to Jasper ?

The problem isn't isolated to an "edge" case, it affects the standard way apps
are deployed.  Thus the numerous other people who have encountered it.  As for
my patch being "complex" that's just not true. I added 2 fields to the generated
servlet class and updated the isOutDated logic to use them.  It took all of an
hour to code and test.  I can't believe you're asking me why I wanted to fix
something that is broken rather than bandaid it.



-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-04-28 00:44 ---
(In reply to comment #47)
> Its also too bad that even with patches charitably submitted, that bugs can't 
> or
> won't be fixed in Jasper.

As I said earlier, I don't think fixing the edge cases is worth adding the
related complexity. It's very simple. As for JBoss "fixing" it, Tomcat "fixes"
it too: you simply need to undeploy/redeploy webapps, and/or add some listener
to clean up the work directory, which is trivial to do. If that's all you want
to achieve, why did you focus on a complex patch to Jasper ?

BTW, feel free to post more useless rants, esp in conjunction with Gili, I enjoy
them :)


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-04-27 21:35 ---
http://jira.jboss.com/jira/browse/JBAS-3081?page=all
JBoss was one of the last standouts, it was relying on Jasper to decide to
recompile or not.  No more.  Now everything gets recompiled on every redeploy. 
At least we can count on the correctness of its behavior now.  

Too bad for the performance that according to some comments here was of such
paramount concern.  

Its also too bad that even with patches charitably submitted, that bugs can't or
won't be fixed in Jasper.



-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-04-06 18:07 ---
Anyone?  Bueller?


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-23 20:15 ---
I uploaded the diffs for the 4 changed files.  This fixes the problem completely
and addresses any and all concerns brought forth in the comments so far.  What
happens next?

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-23 20:12 ---
Created an attachment (id=17958)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17958&action=view)
JspServletWrapper.java diff


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-23 20:11 ---
Created an attachment (id=17957)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17957&action=view)
JspSourceDependent.java diff


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-23 20:11 ---
Created an attachment (id=17956)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17956&action=view)
Generator.java diff


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16492|0   |1
is obsolete||
  Attachment #16493|0   |1
is obsolete||
  Attachment #16599|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2006-03-23 20:10 ---
Created an attachment (id=17955)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17955&action=view)
Compiler.java diff


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-23 13:35 ---
(In reply to comment #39)
What you wrote is totally correct.  I don't want to confuse the issue so I'll 
shut up now.  :)

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-23 02:59 ---
(In reply to comment #38)
Scott, I think I understand your point, but not fully.  Is the lag you refer to
the lag of loading the class twice vs. once, in the case of the .jsp being
outdated and its class not already loaded?  
As I understand it, if either the .jsp is not outdated, or the class is already
loaded, there would be no extra lag.  Is that correct?  I think I might be
missing something, or perhaps Tomcat works differently from Websphere.  Or are
there situations other than an incoming http request that trigger the outdated
check?

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-23 01:44 ---
Jonathan, I have one caveat about using the servlet member data for the 
storing the timestamp of the JSP itself and using it for outdated check 
instead of using the JSP source and class file timestamps.  The problem is 
that the servlet class has to be loaded in order to retrieve this data.  
Therefore, you wouldn't know a servlet class file was outdated until you'd 
already loaded it once (first request). We decided that this 'lag' was ok for 
dependency checking (which by the way is turned off by default in WebSphere) 
but did not like this lag for the top-level JSP reloading.  As I said, just a 
caveat.

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-23 01:02 ---
(In reply to comment #36)
Scott, thanks! That helps a whole lot.  I hadn't considered storing the
lastModified times of the dependencies as member data of the servlet.  It is the
ideal place.  In fact, Tomcat already stores the dependency list there.
I am currently testing a fix which stores the dependant lastModified times
there, as well as the lastModified time of the .jsp (rather than modify the
timestamp of the .class and .java files).  The comparisons made are all !=
instead of > .
I will post a new patch once I've tested my changes more thorougly.




-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-22 18:54 ---
Jonathan, just to clairfy:  WebSphere doesn't store the timestamp information 
in comments - what is stored in comments is informational data that can be 
used to help debug problems.
The timestamps used by the outdated checks are stored in the generated 
classfile as part of the _jspx_dependants List.  If you were to look at the 
generated .java source you would see, for example:

  private static String[] _jspx_dependants;
  static {
_jspx_dependants = new String[2];
_jspx_dependants[0] = "/Banner.jsp^1082410708000^Mon Apr 19 17:38:28 EDT 
2004";
_jspx_dependants[1] = "/Footer.jsp^1077657462000^Tue Feb 24 16:17:42 EST 
2004";
  }

The timestamp simply follows a dependent's path information.

The data in comments the I referred to in post #24 is more this sort of thing:

e:/mytempdir/x.ear/y.war/WEB-INF/classes/_ibmjsp/_jsp1.java was generated @ 
Thu Mar 16 14:03:16 EST 2006
IBM WebSphere Application Server - ND, 6.1.0.0
Build Number: v0611.54
Build Date: 3/16/06


The JSP engine configuration parameters were set as follows:

classDebugInfo =  [false]
debugEnabled =[false]
deprecation = [false]
compileWithAssert =   [false]
etc. etc. etc.

Hope this helps.


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-22 17:57 ---
(In reply to comment #34)
Tom,  I see the problem with the dependants;  that is a huge problem with my 
patch.

I think it is worth solving this problem completely, in a manner similar to the
way Websphere does (see comment #24 and do the google search).  To do this, it
is necessary to compare the current and last timestamps of the jsp and all its
dependants.  Websphere persists this information in the comments of the
generated .java file.

I don't like the idea of putting the timestamps in the comments ala Websphere,
it will mean making changes in more places, and also I am not a fan of parsing 
text.

I am thinking along the lines of creating a seperate file which could be as
simple as a serialized hashmap containing the URLs as keys and the timestamps as
values.

Thoughts?

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-22 03:29 ---
Jonathoan, I was about to try using your patch and noticed a problem.   You are 
using the date of the 
JSP file to stamp the class file but the isOutDated() method is also taking 
into account the times of the 
included JSP files.   This can cause a JSP file to be re-compiled on every hit 
if it includes a file that has a 
later date. 

For example, if a.jsp is time-stamped 9:00 and it includes b.jsp which stamped 
10:00, then isOutDated
() will always return true because the time of the included file is greater 
than 9:00.   Then when you 
assign the earlier time to the class file, this check will fail again the next 
time around.

I think a better solution is to set the time of the class file to the greatest 
time of the compiled file AND 
ALL of it's dependants.   In the above scenario, the class file would get a 
time stamp of 10:00 instead of 
9:00 and subsequent checks of isOutDated would return false as expected.   The 
only problem I can 
forsee is if someone updates the included file, THEN rolls back the original 
file.   That seems like a very 
obscure case and my solution is still better than the current solution which 
doesn't account for 
rollbacks at all (and also wouldn't handle the obscure case).

I will attempt a solution but will be on vacation soon so it may be a while 
before I'm able to post any 
patches. 

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-22 00:22 ---
(In reply to comment #32)
Sorry for getting the patch backwards.  Not that it matters, it will probably 
never be incorporated any way, due to the co-location of a certain person's 
head with his ass.
Do the votes matter?  I am the only one voting for this, perhaps if a few more 
people used their votes it would show up on a list somewhere, causing some 
action to be taken. 
Other than patching Tomcat, here's what I recommend, in order of preference:
1) Don't use Tomcat.
2) Don't use JSPs.
4) Precompile your JSPs as part of your build process.


-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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]  2006-03-21 23:45 ---
I think the patch files are backwards (show how to remove the fix) but that 
doesn't make this bug less 
important.   We just got bit by this thing again... every couple of month at my 
company.   It's time to bite 
the bullet and make a one-off version.   Is it ever going to be fixed?

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-11-16 17:05 ---
Fabien,

The jasper-compiler.jar I built was against 5.5.9, I think that's the problem. 
It should work just fine if you patch and rebuild.

-Jonathan

(In reply to comment #30)
> (In reply to comment #28)
> > Created an attachment (id=16599)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16599&action=view) 
[edit] [edit]
> > rebuilt jasper-compiler.jar
> > 
> > Here is a rebuilt jasper-compiler.jar that incorporates my proposed patch.  
> > For
> > anyone who needs a fix and doesn't want to download, patch, and rebuild.
> 
> Hello Jonathan,
> 
> i've tried tu use your jasper-compiler.jar into TC 5.5.12, because we have a
> problem to make Tomcat reload and compile modified JSPs on fly, but an 
> exception
> is thrown when Jasper try to compile the JSP.
> 
> i haven't try to patch an rebuilt yet.
> 
> Here is the root cause of the stack trace, it seem like an import from an
> Eclipse library :
> 
> java.lang.NoSuchMethodError:
>
org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer.(Lorg/eclipse/jdt/internal/compiler/env/IBinaryType;)V
>   org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:214)
>   org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:183)
> 
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:119)
> 
org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
>   
> org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2111)
> 
org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:62)
> 
org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:141)
> 
org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:104)
> 
org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1088)
> 
org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:755)
> 
org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:927)
> 
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:254)
> 
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:195)
>   
> org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:301)
>   org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:315)
>   
> org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:387)
>   org.apache.jasper.compiler.Compiler.compile(Compiler.java:288)
>   org.apache.jasper.compiler.Compiler.compile(Compiler.java:267)
>   org.apache.jasper.compiler.Compiler.compile(Compiler.java:255)
>   
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:557)
>   
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:293)
>   org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
>   org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:802)



-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-11-16 15:42 ---
(In reply to comment #28)
> Created an attachment (id=16599)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16599&action=view) 
[edit]
> rebuilt jasper-compiler.jar
> 
> Here is a rebuilt jasper-compiler.jar that incorporates my proposed patch.  
> For
> anyone who needs a fix and doesn't want to download, patch, and rebuild.

Hello Jonathan,

i've tried tu use your jasper-compiler.jar into TC 5.5.12, because we have a
problem to make Tomcat reload and compile modified JSPs on fly, but an exception
is thrown when Jasper try to compile the JSP.

i haven't try to patch an rebuilt yet.

Here is the root cause of the stack trace, it seem like an import from an
Eclipse library :

java.lang.NoSuchMethodError:
org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer.(Lorg/eclipse/jdt/internal/compiler/env/IBinaryType;)V
org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:214)
org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:183)

org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:119)

org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)

org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2111)

org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:62)

org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:141)

org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:104)

org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1088)

org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:755)

org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:927)

org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:254)

org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:195)

org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:301)
org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:315)

org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:387)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:288)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:267)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:255)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:557)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:293)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

-- 
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]

DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|P3  |P1




--- Additional Comments From [EMAIL PROTECTED]  2005-10-19 22:59 ---
We got bit by this bug again today!   How can I impress on the developers the 
seriousness of this issue?

We need to touch every JSP file when we deploy a webapp because we cannot trust 
that Tomcat will 
recompile the things that need to be.   This causes large delays to the end 
users that are unlucky enough 
to hit the website first.

If you revert your JSP files to an older branch, you also have to remember to 
touch them (many CM 
systems revert the dates to the older version which still pass the < 
comparison).

I think Jonathon's fix will address every realistic scenario.Please use his 
patch!


-- 
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]