Programmatically undeploying a webapp

[Guilherme Rios <ga...@gmail.com>]

Hi,

    I am trying to understand the internals of undeploying an
application. After looking at the source code of

org.apache.catalina.manager.ManagerServlet

as available in the source package for apache-tomcat-6.0.24,
specifically the part that starts at line 1361 (may differ from the
current repository version, but hopefully not by much) inside method 

undeploy(PrintWriter writer, String path)

I still could not figure out a few details:

1. Are the calls to "addServiced(path)" (line 1362) and
"removeServiced(path.replace('#','/'))" (1386) there just to keep
someone else to try and undeploy the app while we are already doing it
or do they serve some other purpose?

2. Why calling "check(path.replace('#', '/'))" at line 1384? Would
undeploy work just the same without this call?

3. Is undeploying, at least as far as ManagerServlet and classes
operating at the same layer are concerned, just about erasing the app's
WAR file, or its directory if there is no WAR, or its config file if
there is neither?

    I ran a few tests and noticed code that just erases the relevant
files does work, but really seem overly simplistic, so now am asking
myself where to draw the line.

Thanks in advance, any help is appreciated

Guilherme


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Programmatically undeploying a webapp

[Mark Thomas <ma...@apache.org>]

On 14/03/2010 00:44, Guilherme Rios wrote:
> Thanks Mark, just one minor clarification please:
>
> On Sat, 2010-03-13 at 22:44 +0000, Mark Thomas wrote:
>>
>>> 2. Why calling "check(path.replace('#', '/'))" at line 1384? Would
>>> undeploy work just the same without this call?
>> Support for contexts with paths of the form /foo/bar.
>> Tomcat converts this to foo#bar when it creates the directory.
>
> Got it, but my question was why calling check() at all at this point?
> There is a comment nearby saying "perform new deployment", what does it
> mean? I am guessing the call to check() speeds up updating the internal
> state after undeploying and that's all there is to it. Am I missing
> something more critical that might be happening here?

It is forcing the deployment process. Two reasons:
1. So the manager knows the app is deployed
2. autoDeploy may not be enabled for the host so the deployment has to 
be manually triggered.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Programmatically undeploying a webapp

[Guilherme Rios <ga...@gmail.com>]

Thanks Mark, just one minor clarification please:

On Sat, 2010-03-13 at 22:44 +0000, Mark Thomas wrote:
> 
> > 2. Why calling "check(path.replace('#', '/'))" at line 1384? Would
> > undeploy work just the same without this call?
> Support for contexts with paths of the form /foo/bar.
> Tomcat converts this to foo#bar when it creates the directory.

Got it, but my question was why calling check() at all at this point?
There is a comment nearby saying "perform new deployment", what does it
mean? I am guessing the call to check() speeds up updating the internal
state after undeploying and that's all there is to it. Am I missing
something more critical that might be happening here?

It looks like ManagerServlet could use a cleanup (unused local variables
and stuff). I would be glad to review it and submit a patch, if no one
else is working on it. Should I talk to someone in particular, or maybe
submit a bug and attach the patch to it?

> Look at the StandardContext.stop() method if you want to understand 
> things in more detail.

Will do. Thanks!


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Programmatically undeploying a webapp

[Mark Thomas <ma...@apache.org>]

On 13/03/2010 14:09, Guilherme Rios wrote:
> 1. Are the calls to "addServiced(path)" (line 1362) and
> "removeServiced(path.replace('#','/'))" (1386) there just to keep
> someone else to try and undeploy the app while we are already doing it
Yes.

> or do they serve some other purpose?
No.

> 2. Why calling "check(path.replace('#', '/'))" at line 1384? Would
> undeploy work just the same without this call?
Support for contexts with paths of the form /foo/bar.
Tomcat converts this to foo#bar when it creates the directory.

> 3. Is undeploying, at least as far as ManagerServlet and classes
> operating at the same layer are concerned, just about erasing the app's
> WAR file, or its directory if there is no WAR, or its config file if
> there is neither?
There is a little more to it. The various components (Servlets, Filters, 
context etc) are stopped which triggers things like 
ServletContextListeners and - if all goes to plan - allows the resources 
to be GC'd.

>      I ran a few tests and noticed code that just erases the relevant
> files does work, but really seem overly simplistic, so now am asking
> myself where to draw the line.
Look at the StandardContext.stop() method if you want to understand 
things in more detail.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org