tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ankur Shah <>
Subject Re: JSP not reloading
Date Tue, 23 Dec 2003 18:14:40 GMT
A few things to try here:
1. What happens when you access your JSPs directly through tomcat (port
8080?). Do you get the same result?
2. What happens when you do "$touch foo.jsp"? Does your server pick up
the changes, then?
3. Did you try upgrading to 5.0.16? *duck*

Mike Curwen wrote:

>Alright, I've tried upgrading to 4.1.29.  The exact same behaviour is
>occuring with this version as well!
>I'm kinda desperate here... developing under these conditions is
>negative fun.  
>Someone just give me a hint! Anything!!  :)
>>-----Original Message-----
>>From: Mike Curwen [] 
>>Sent: Monday, December 22, 2003 12:18 PM
>>Subject: JSP not reloading
>>Hi everyone,
>>This has been covered before, I know.  But there doesn't seem 
>>to be a common agreement on what the problem (and therefore 
>>solution) is. 
>>Our Tomcat 4.1.24 instance has spontaneously decided to no 
>>longer recognize JSP changes! I say spontaneously, because we 
>>were running fine, in production, a number of different 
>>sites.  As it happens, a couple of these sites are getting 
>>'tweaked'.. and so there are a large number of 'small 
>>changes' being made to the JSP pages. And as of Thursday last 
>>week, here's what we're observing...
>>>>From the 'ok' state, we can get away with making one change to a JSP
>>page.  Then we click refresh in the browser, and see the 
>>change we made. For every subsequent change to the JSP, the 
>>change is NOT reflected in the browser.  That page is now 
>>considered in the 'not ok' state.  We go for lunch, or come 
>>back the next day.  If we make a change, it is recognized. 
>>(So the page was back in the 'ok' state)... but like before 
>>lunch, or yesterday, after that one change, it's back to the 
>>'bad' state.  
>>This applies to JSPs invoked from the address bar, AND 
>>through a JSP Include on the server-side. Even after 
>>'touching' the parent JSP, the 'included' one still appears 
>>as the 'old' version.
>>The ugly hack:  If my JSP is called foo.jsp, I edit foo.jsp 
>>for my changes.  Then in a command line window I type cp 
>>foo.jsp fooX.jsp (where X is an ever increasing integer). And 
>>then I call fooX.jsp from the browser. 
>>To ugly fix: We must stop Tomcat, clear the work directory's 
>>folder for that web app, and restart.  Then we're back to 
>>every page in the 'ok' state for just one change.
>>There have been *zero* configuration changes to any of 
>>httpd.conf, workers.proprties and server.xml files in the 
>>timeframe of when it all went south.
>>It's not the 4.1.27 reloading issue.
>>We're on the internal network, there is no proxy caching.
>>It's not browser caching. 
>>It's not a server timestamp out of sync.
>>Here's one thing of interest: One of the contexts that is 
>>under development has the reloadable=true in its Context 
>>entry. The other does not.  But that aside, BOTH of these web 
>>apps were reliably picking up changes, up until last week. 
>>(Does reloadable have anything to do with JSP's or just items 
>>under WEB-INF ?)
>>Slackware 9
>>Apache 2.0.45
>>Tomcat 4.1.24
>>JK (not sure of version)
>>Has anyone run into this behaviour??  Is there a FAQ or 
>>google page covering this?
>>I know this little bug has been around in some form or 
>>another for quite some time. Here's one entry: 
>I'm thinking I'll have to try upgrading to 4.1.29.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message