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]
