tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Tomcat 4.1-dev web application management current design & proposal for improvements
Date Sat, 02 Mar 2002 16:06:59 GMT
  Tomcat 4.1-dev HEAD web app management current design and proposal for improvements
Current Behaviour
Here is a stab at documenting how the Tomcat 4.1 dev HEAD CVS branch
manages web applications based on reviewing user documentation, code,
and testing.  Please review and add corrections if needed.
Tomcat Startup
Context's configured in server.xml deployed.

if( autoDeploy == true )

  Deploys Context configurations found in appBase/*.xml.
    calls host.install() with a file URL to Context xml config file.
    The Context *.xml file can specify any directory on the server
    as the docBase and it will be instantiated as a Context, as long
    as the SecurityManager doesn't prevent access.

  Deploys *.war files found in appBase/*.xml
    if( unpackWARs == true )
       calls host.install() with a file: URL after expanding the war file.
    if( unpackWARs == false )
        calls host.install() with a jar:file: URL to war.

  Deploys directories found in appBase.
    calls host.install() with a file URL to directory.

Tomcat runtime AutoDeploy 

A background thread is started.

if( autoDeploy == true ) 
   the actions above for autoDeploy are taken each 15 seconds.

Contexts are checked for a modified web.xml, if detected the
Context is stopped then started again.

Tomcat Manager

- deploy ** Not available via HTMLManagerServlet

Installs a web application using a war file sent via an HTTP PUT.
The deployed application does not persist if Tomcat is restarted.

- install
Installs a web application using a remote Context config xml
file and a war file or directory located on the server.              
You can specifiy any file URL as long as the SecurityManager
doesn't prevent access. Such as "file:/". And the Context config
xml file can specify any docBase.  The installed application does
not persist if Tomcat is restarted unless the directory or war
file existed in the Host's appBase.

- start

Starts the Context if it exists and is currently stopped.

- reload

Reloads Context if it is a directory, does not reload if
it is running from a war file. A reload does not reload
the web applications web.xml. So if you make configuration
changes to the web.xml file you need to do a stop/start.

- stop

Stops the Context if it exists

- remove

Removes the Context from a running instance of Tomcat and
stops it.  Does not remove any files.

- undeploy ** Not available via HTMLManagerServlet

Removes Context from host, delete's app directory or war file.
Does not delete work dir.

- list

Lists information on existing contexts.

- sessions

Lists information on the number of sessions for Context

Tomcat Shutdown

Each Context is removed using Host.remove(contextpath).
This removes the Context object from the Host container
and performs a Context stop().



Here is a proposal for improving how Tomcat manages web applications.
My goals in creating this were to address security concerns and to
improve the ability for virtual hosted customers to manager their
own applications. Please review.


Suggestions for improvement

The install and deploy manager tasks along with the autoDeploy
of a Context *.xml in a Host's appBase make it possible for
someone who has access to the manager or write file access to
the appBase directory on the server to specify a docBase any
where on the server Tomcat is running on.  When virtual hosting
customers sites this is a big security problem.

Restrict instantiation of Contexts to a directory or war
file located in the Host's appBase. If this is too restrictive
for some, then add a Host attribute of globalDeploy=(true|false)
with a default of false.  If globalDeploy is true an application
can be deployed using a file or war from outside of the Host's


Here are some inconsistencies in the HostConfig

A background thread is always started.  From the comments
for the thread methods it isn't clear what it does.

In some places the comments talk about session timeouts,
in other places checking for modified classes, and in other places
it mentions checking for shutdown, and the checkInterval variable
says check periodically for web app deployment.

Looking at the code, this is what it does.

Every 15 seconds it wakes up.

  if autoDeploy=true, it checks for new web apps to deploy.

  Then it checks each context to see if the web.xml has changed.
  If it has changed it does a stop, then start of the Context.

Suggested improvements

Cleanup the misleading comments.

There is only one flag used for determining if you want
autoDeploy which applies both at startup and runtime interval

These two should be separate.  It is very likely that you would
want autoDeploy at Tomcat startup, but not checks at 15 second
intervals. Remove the autoDeploy attribute and add the following:

startupAutoDeploy=(true|false) default = true
intervalAutoDeploy=(true|false) default = false

The checks for a modified web.xml which stop then start a Context
should only be done if intervalAutoDeploy=true. I haven't found any
user documentation about Context start/stop if the web.xml is modified,
document this feature.

Only start the background thread if intervalAutoDeploy=true.

Deploying applications using a Context *.xml file located in the
Host's appBase or via the manager servlet is a security problem.
Instantiation of a new Context runs with the SecurityManager permissions
granted to catalina.  This allows anyone with write access to the
appBase directory for a Host or access to the manager servlet to configure
directories and war files anywhere catalina has file read permission.
This affects the docBase, workDir, and loggers.

Add an attribute to disable it:

deployXML=(true|false) default=false



The install task used to support any URL, now it only
supports URL's for local files on the server.  But
HTTP PUT was implemented for the deploy task. Was this
changed to get around the JVM bug related remote access
to and reading of a JAR (zip)? I checked the CVS log
for the ManagerServlet and it wasn't mentioned.

Suggested improvements

- deploy

Currently war files deployed do not persist past a Tomcat restart.
That makes this pretty useless for someone to use for managing their
applications on a production system.

If the Host unpackWARs==true
  Install the war file in the Host's appBase as {context-path}.war.
  (The war is required to exist in order to perform the new update task)
  Expand the war file into a directory named {context-path} in the
  Host's appBase.  If the directory or war file already exist in the
  Host's appBase, the deploy should fail.

If the Host unpackWARs==false
  Install the war file in the Host's appBase as {context-path}.war.
  If the war exists in the Host's appBase, the deploy should fail.

- install

Change the name to "add", install implies you are putting
something on the server.  And "add" is the counterpart to remove.
So "add" would add a Context configuration, "remove" removes a Context

Make it easier to specify a war or directory within the Host's
appBase.  If the URL is not a file URL create a file URL relative to
the Host's appBase.

- start

- reload

- update

Add a new task called update.  Requires a context path for an
existing Context and performs an HTTP PUT of a new war file.

Some applications need to exist in a context directory because they
need to manage data files stored within the context directory.  An
update allows for the web application resources to be updated without
removing any existing data generated by an application.

if the Host unpackWARs==false
  Stop the Context, remove the War file, remove the Context workDir.
  Install the new war in the Host's appBase and start the context.
  Kind of a one step undeploy/deploy.

if the Host unpackWARs==true
  If the context doesn't exist, fail.  If the context directory or
  the war file doesn't exist, fail.

  Stop the Context. Remove any files in the Context directory which
  exist in the old war file.  Remove the old war file. Remove the
  Context workDir.

  Install the war file in the Host's appBase as {context-path}.war.
  (The war is required to exist in order to perform the new update task)
  Expand the war file into a directory named {context-path} in the
  Host's appBase.

- stop

- remove

- undeploy

Delete workDir in addition to deleting Context directory or
war file when undeploying a Context. Per the Servlet spec
the workDir isn't required to be maintained across container
restarts, so there should be no problem removing it when an
application is undeployed.

- list

- sessions

Add the ability to track session creation by the request URI
which created the session.  I haven't looked into how hard this
would be to implement.  A web application which handles alot of
unique visitors can end up creating 1000's of sessions.  This eats
up JVM memory and affects performance. The default behaviour of a
JSP page is to create a session. Listing what request URI
created a Session and how many will make it much easier to find
and fix those JSP pages, etc. which are creating unnecessary sessions.


Suggested improvements

Add the deploy task.

Add the undeploy task. This should include a confirmation page
before actually undeploying the context path.

Add the update task.  This should include a confirmation page
before actually performing the web application update.

Increase the font size for the context information, using Netscape 4.7
I can barely read it.


Create a new ant task for performing updates.




Glenn Nielsen    | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message