Let's say I have a war called com_mysite_www.war. I set tomcat up so that it does auto-deploy but it doesn't unpack the wars. I also set com_mysite_www as the default app. I deploy the war file (by copying it into the webapps dir or using the manager app) and tomcat behind the scenes unpacks it to it's work directory (as it would be terribly inefficient to unpack it every time a request was made). Then go back to manager app and undeploy it (or just manually delete the file .war out of the webapps dir).. now hit localhost:8080... the .war is gone but your site remains. That isn't surprising but what happens next is. Now change something, make a new .war and deploy it. When you hit localhost:8080 you will still see the old content however if you hit localhost:8080/com_mysite_www/ you will see the new content. The only way to get it to reflect the changes when you hit the root is to restart tomcat. I have tried everything I can think of and read through many postings, tomcat books and the tomcat site but I can find no solution for this other than a server restart.
It's odd stuff and I'd love to find out if others have experienced this and how they deal with it. Personally on my dev machine I do it the brute force method.. I have an ant script that bulids my .war, deletes the old content out of the webapps dir and then deploys the new one for me. I can't do this on the live server though but it does work as intended which is more than I can say for the suggested methods of redeploying a .war in the tomcat docs. :)
Thinking about your suggestions, I wonder if I were to copy in my new .war and then go to the deployed directory and remove the web.xml if it would choke on that and try to fix the problem by redeploying from the war which in this case would be updated. Still an ugly hack of a work around but it would limit the downtime to just that one app and it'd be less of a downtime than restarting the server.
-Torrey
Bernard wrote:
Hi Torrey,
I can't comment on .war file deployment directly because I am not using it. But I want to help you anyway, suggesting the approach I would take.
I would forget manager for a moment. A basic servlet engine (these things have been around for 10 years or more, remember Sun's Java Server) are capable to reload servlets if any of the watched resources change.
Server restart for your purpose is a very sad state of affairs, not acceptable by today's standards.
So I would try to touch any of the watched resources, e.g. a servlet class file, a servlet jar file or the web.xml file.
That, from my experience with old mod_jserv, does not immediately trigger class re-loading. Only the next servlet request provides the event for that (noticable delay of servlet response).
If that does not work, then you have the most basic problem. If it works, then you have a feeling for how it should work. Then work your way up to war file deplayment with manager. I would think that you don't need manager for most management tasks e.g. war file deployment because who can assume that you want to introduce a security risk by providing such powerful access to your application via http???
Playing around a little is sometimes very useful.
Regards,
Bernard
On Thu, 17 Mar 2005 18:50:40 -0800, you wrote:
I have a similar problem in 5.5 when deploying my .war files. If I go to the manager and undeploy a webapp that was deployed from a war it only deletes the .war file and not the exploded directory. If I want to deploy an update I have to stop tomcat and start it again for it to pickup the change in the war file. Even when I have auto-deploy set to true.
I have done everything I can think of but it seems that to make an update like this in Tomcat you have to stop and restart which is really unfortunate.
Bernard wrote:
---------------------------------------------------------------------Roland,
You might want to add yourself to the cc list of this bug:
Normal startup causes server error 500 http://issues.apache.org/bugzilla/show_bug.cgi?id=34050
It might be in the area of your interest.
Regards,
Bernard
On Thu, 17 Mar 2005 11:02:57 +0100, you wrote:
Hi,
To reload, start, stop, deploy, undeploy contexts see the Manager : http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html
I don't know your tomcat version, but it works since TC 4.
Cheers.
On Thu, 17 Mar 2005 08:32:54 +0100 Roland Carlsson <[EMAIL PROTECTED]> wrote:
---------------------------------------------------------------------Hi!
I have a problem with an webapp with deploying webapps. The problem is the contextfile that since my development environment differs a little to my deployment environment have to be edited a little after deployment. But how do I force tomcat to re-load the context? Right now the only way I know about is to reboot tomcat witch leads to a full stop of all my web-apps instead of only one witch in turn leads to more complaints from my users.
So, is there a way to force reload of the context when reloading the web-app?
Thanks in advance Roland Carlsson
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
