-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anand,
On 4/20/2010 7:26 PM, Anand HS wrote: > 1. A simple agent ( can be a java program inside my web app itself ) senses > there is an update. > 2. when an update is available, it stops the tomcat server. Step 1: Firmly grab the rug under your feet Step 2: Pull quickly Step 3: ??? Step 4: Profit > 3. Applies the update ( similar to redeploy along with configuration file > changes ) . > 4. restarts the tomcat. I agree with Pid: update the webapp, but don't restart Tomcat. Restarting Tomcat might be difficult if the updating software is actually running within Tomcat. > I need advice from the community on other approaches as well as any support > tomcat provides out of the box. Tomcat will not help you at all, except for some of the utilities it may provide to help you re-deploy a webapp (such as the deployer ant task, or the manager app itself). First, I would provide two apps to your customers: the first is the actual webapp itself, and then provide a second app to check for updates. There's no requirement that the updater be a webapp, nor that it even be written in Java. One of the first questions you need to ask yourself is what is involved in an update? Typically, code updates can be done either with patches (or, at least, new copies of only the files that have changed) or with a completely new WAR file. Which do you prefer? The former will likely result in quicker update times, but will be more difficult to implement. What about data storage changes? Does your webapp know how to startup and make whatever changes are necessary in order to ensure a sane environment for itself? Many PHP-based webapps are like this (Bugzilla, Wordpress, etc.) but I've never seen a Java webapp do it. Maybe I just don't deal with too many webapps that I haven't written myself :) If your webapp isn't this smart, you'll either have to make it smart, or implement this data storage upgrade as part of your "updater" app. Next, you have to think about how automated this should be: is it okay to bounce a customer's Tomcat in the middle of the day? You might want to have some options for scheduling these update checks and scheduling the actual updates themselves. Finally, once you've figured out how to update your data and your code, it's trivial to build a new WAR file (or exploded WAR directory structure) and have Tomcat redeploy it: you'll need to have the "manager" app installed. The manager can be used to deploy, undeploy, or redeploy any webapp using simple HTTP GET requests. See the documentation for the manager app on the TC site for more information. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvPYqEACgkQ9CaO5/Lv0PCoCgCfch6PnbF+KtE9/veFgoeIN+Ri GU8An3HJjEmkAj+Kb3Ot/4LUMuftJraQ =/4Ql -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
