It is definitely NOT a client-side cache issue. One a completely separate machine that has never loaded that page, I'll get the 'old' output of the JSP. And regardless of this, this *did* work up until last week, on one machine, using one browser (IE 6).
> -----Original Message----- > From: MS [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 23, 2003 11:44 AM > To: Tomcat Users List > Subject: Re: JSP not reloading > > > Which browser are you using? I've had some caching problems with IE. > > ----- Original Message ----- > From: "Mike Curwen" <[EMAIL PROTECTED]> > To: "'Tomcat Users List'" <[EMAIL PROTECTED]> > Sent: Tuesday, December 23, 2003 12:23 PM > Subject: RE: JSP not reloading > > > > 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 [mailto:[EMAIL PROTECTED] > > > Sent: Monday, December 22, 2003 12:18 PM > > > To: [EMAIL PROTECTED] > > > 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: > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg > > 99927.html > > > > > > I'm thinking I'll have to try upgrading to 4.1.29. > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]