DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=26372>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 java.lang.ThreadDeath when trying to reload an application ------- Additional Comments From [EMAIL PROTECTED] 2004-10-14 08:06 ------- sorry you thought it was a rant, it wasn't meant to come over like that :) i suppose because tomcat has a manager application and reloadable class facility, i assumed it should do that gracefully in all circumstances. it is true i don't fully appreciate all the issues with this feature so i suppose this is just an issue we have to workaround. In fact, the workaround has been listed here now. It is also true that this is in our case was always related to a development instance. I am interested in your comment that reload of webapp is mostly trouble and limited in production environments though. My understanding was that if you want to make a build to production or a patch of some files, you would use ant or similar as we do here to reconstruct the WAR to deploy. Does this not require tomcat being able to reload? In fact, we tell the business the intranet will be down for 5 minutes and post a message page up for inbound requests. We stop tomcat, delete the old war and expanded war files and place the new war and startup tomcat again. We constantly get irked by the fact that if a bug is on production we have to wait until the evening to patch it whereas our ASP coutnerparts can so easily hot-patch. We also use JSP precompilation to improve performance so it's not so easy to patch JSPs either. Anyways! Cheers PS: this was not a rant ... just inquisitive ;) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
