Why not move to the more "traditional" way and deploy your application as a .war and not as an expanded directory with classes and jsp's in it.
In your ant build script (assuming you are using ant), you can build your .war which also includes precompiling your JSP's with jasper. Then use the tomcat ant tasks to just reload the application. You'll be sure that the latest compiled version of the jsp is running. Also, that delay when you first access a jsp (waiting for it to be compiled on the fly) will be gone. If it is absolutely required than the application must ALWAYS be available, then this is probably not an option, but the reload takes a few seconds. --- Mike Curwen <[EMAIL PROTECTED]> wrote: > 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]/msg99927.html > > > I'm thinking I'll have to try upgrading to 4.1.29. > > ------------------------------------------- > Mike Curwen 204-885-7733 > Intermediate Programmer www.gb-im.com > ------------------------------------------- > ____ ____ ___ __ __ > / ___| | __ ) |_ _| | \/ | > | | _ | _ \ _____ | | | |\/| | > | |_| | | |_) | |_____| | | | | | | > \____| |____/ |___| |_| |_| > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
