Let's be frugal and use just 2 "instances of a webapp".
How do you run "2 instances of a webapp"?
You must deploy them. How do you do that?
You drop a war file for each into webapps.
Whoa! Did you "drop 2 copies of myapp.war into webapps"?
You can't do that. If they are both named myapp.war, when you drop in
the 2nd one, it overwrites the first.
Ok. So you name them myapp1.war and myapp2.war, and drop them both in
webapps.
Cool. In one sense they both look like the same webapp, but they are
different entities from Tomcat's point of view.
So if you use the manager to stop myapp1, nothing will happens to
myapp2 -- it is totally physically distinct from myapp1.
Ergo Watson, we've solved the morning star/evening star paradox.
--Ken
On Mar 11, 2009, at 10:39 AM, André Warnier wrote:
Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Tomcat for
Dummies
If I am not abusing, how does it do that, schematically ?
I presume it has a more direct way than to itself isue a HTTP
request to the Manager webapp with the appropriate
parameters ?
No, the HTTP request would be the simplest approach. There's
likely a JMX call that could be done, but it would be more work.
Certainly there are internal APIs that could be used, but those are
subject to change at any time, and are normally not available to
regular webapps.
And if it asks to undeploy itself, is it not like pulling the
carpet from under its own feet ? I mean, this webapp is running,
and even after asking the Manager to undeploy itself (meaning its
whole shebang of classes and libs will
be erased from the disk), it should be able to still stop itself
cleanly.
That should be handled by a ServletContextListener declared in WEB-
INF/web.xml, which will be invoked before the deletion of the
webapp's files.
More seriously thus, there seems to be a problem with this logic :
Suppose we have a case where 5 instances of this webapp are
currently running, and one of them issues a request to the Manager,
to undeploy itself. The Manager would then oblige, and start
undeploying the webapp. The ServletContextListener in each of the
running webapp instances would be called, before the Manager does
anything drastic. Presumably then each ServletContextListener
instance would have to take some action to force the corresponding
webapp instance to stop and cleanup its act, and also presumably the
Manager would wait for each of these instances to return some form
of OK, before it proceeds with erasing the webapps files.
But is that really what happens ?
I feel somewhat uncomfortable with the above scheme, more out of a
gut feeling than anything else. Am I wrong ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
