THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Anchor | ||||
|---|---|---|---|---|
|
Tomcat 5, Tomcat 6:
| Wiki Markup |
|---|
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 inas the {{META-INF/context.xml}} directory ofin your webapp, and use Tomcat's Manager webapp to deploy/undeploy your applications. More details can be found here: [MARC Archive|http://marc.info/?l=tomcat-user&m=107590945807699&w=2] |
Tomcat 7:
In Tomcat 7 the default behaviour has been changed to do not auto-create those context configuration files.
| Wiki Markup |
|---|
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.
| Anchor | ||||
|---|---|---|---|---|
|
Because the Classloader (and the Class objects it loaded) cannot be recycled. They are stored in the permanent heap generation by the JVM, and when you redepoy redeploy a new class loader is created, which loads another copy of all these classes. This can cause OufOfMemoryErrors eventually.
...