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]
