This section of the FAQ discusses common questions related to web application deployment.
- Why does tomcat 5 create context configuration files?
- Why does the memory usage increase when I redeploy a web application?
Why does tomcat 5 create context configuration files?
Tomcat 5, Tomcat 6:
Unlike tomcat 4.x, tomcat 5.x creates context configuration files for you in its
conf/[Engine name]/[Host name] directory. This is part of the change in tomcat's configuration mechanism from version 4.x to make overall configuration more robust, flexible, and enterprise-friendly. Note, however, that this has changed the recommended deployment practices for web applications. These context configuration files are created by tomcat, but not removed by tomcat, because the user may have changed them or other files in the conf directory. The suggested practice for tomcat 5 is to place context configuration files as
META-INF/context.xml in your webapp, and use Tomcat's Manager webapp to deploy/undeploy your applications. More details can be found here: MARC Archive
In Tomcat 7 the default behaviour has been changed to do not auto-create those context configuration files.
The recommended practice of using
META-INF/context.xml files is still the same. Those files are discovered and processed in the same way. The difference is that they are not copied to the
conf/[Engine name]/[Host name]directory.
This is convenient, as you do not need to care of those copied files when undeploying your application, and you do not need to care whether the
conf directory is writeable. This change in behaviour is documented in the Migration Guide.
Why does the memory usage increase when I redeploy a web application?
That is because your web application has a memory leak.
A common issue are "PermGen" memory leaks. They happen because the Classloader (and the Class objects it loaded) cannot be recycled unless some requirements are met (*). They are stored in the permanent heap generation by the JVM, and when you redeploy a new class loader is created, which loads another copy of all these classes. This can cause
(*) The requirement is that all classes loaded by this classloader should be able to be gc'ed at the same time.