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 [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]
