Tomcat manager app is documented here: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html
Personally, I don't know what are the current state-of-the-art best-practices for web hosting providers. However, I have to assume that they generally allow their customers to restart their web applications, without affecting their other customers' uptimes. Tomcat 4.x lets you start, stop, reload, deploy (from scratch), and undeploy web applications using the manager interface, all without affecting any other running web applications (and yes, they all share a single JVM). On Wed, 2002-03-13 at 11:27, [EMAIL PROTECTED] wrote: > > I'm curious. I did not know about the manager reload command. Where > can I find out more about it? > Also, if I went with a web-hosting service that had 1 and only 1 tomcat JVM > instance, would the reload command be something the hosting site would > allow me to run? Would the reload command affect all of the other folks > using the same Tomcat JVM instance? > > If so, I would assume that the web-hosting service would not allow me to > use the reload command and thus would still be stuck with the $50 per month > private-jvm instance fee. > > thanks, > Theron > > > > > > Bryan > > Field-Elliot To: Struts Users Mailing List > > <bryan_lists@ne <[EMAIL PROTECTED]> > > tmeme.org> cc: > > Subject: Re: Perhaps TABOO Question, >how to convert struts > 03/13/02 09:35 apps to non-struts > > AM > > Please respond > > to Struts Users > > Mailing List > > > > > > > > > Your assumptions are most likely wrong. Whether or not your Servlet > container supports "hot-redeploy" is a general question, and not at all > specific to Struts. Therefore, the question of whether to strip out > Struts from your application shouldn't even be on the table with repsect > to your concerns. > > I use Tomcat 4.0 as my production server. It supports hot-redeploy by > way of the manager "reload" command, which I can do remotely. As far as > I can tell, this only causes a momentary lapse of responsiveness for the > one web-app I am redeploying, and the rest of my webapps stay running > just fine. No stopping and starting of the entire container is required. > With this mechanism, I can change mappings in struts-config.xml, add new > Actions, update existing classes, etc., all on-the-fly. The only thing > it doesn't do, is reload the "web.xml" file, which, luckily, changes > very infrequently (as opposed to struts-config.xml which changes often). > > Bryan > > On Wed, 2002-03-13 at 10:17, [EMAIL PROTECTED] wrote: > > > > A co-worker and I were talking about this yesterday and I was curious of > > the following.... > > > > Seems like in order to develop a struts application, you'll have to pay > for > > a private JVM instance so you can start and stop the tomcat or other JSP > > engine so that it can re-read the config.xml files.... > > > > Question 1: Any plans for struts to change in the future where you can > > dynamically add new actions and forwards without having to stop and > > re-start the web-server? I would guess (although I could be wrong) > that > > this would be pretty easy to do within struts in the future? I assume > > struts is loading the config files in a DOM. Adding a new servlet > within > > struts to reload the config files and update the DOM does not seem like > it > > would be that difficult... > > > > Question 2: Supposing I wrote this app in struts and I could not find a > > sponser to pay the $50 per month fees to host a web-site... Well, I > > could reconvert the apps to a non-struts approach and then pay only $10 > per > > month (because I would no longer need to start/stop the web-server and > > would only need to dump updated JSP's and such).... Is there a > > document/technique/pattern/advice on the best way to convert existing > > struts applications to non-struts? I know that putting javabeans back > > into the JSP files would be a royal pain but if it would save $40 per > > month, it may be the best way to go :-) > > > > thanks, > > Theron > > > > > > -- > > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
