One condition that can cause this is having class files with a future date. This can happen if the machine that you copied them from didn't have it's clock set properly.
Since the date on the class files is higher than the JSP file, jasper won't recompile it. Zap all the class files in your work directory. On Tuesday 23 December 2003 12:23 pm, 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 [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] -- Ben Souther F.W. Davison & Company, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
