One of the things I really enjoy about Open Source software is that you can sometimes get useful insights from people smarter and more experienced than yourself. I had an interesting discussion with Josh Rehman on the relative merits of deploying web applications using the server.xml method or using the context descriptor method.
Josh's position is that the context descriptor method should become the canonical method for web application deployment for many reasons: the unreliability of server.xml edits propagating through the server, and the difficulty of removing those contexts that are already deployed.
I had not considered that position before, probably because I do not run Tomcat in a high volume, mission-critical environment. Things are different in the little corner of Asia where I stay and work. The traffic is much lower and you can pretty much reboot the server anytime you wish. So bringing down the Tomcat server process to add, modify or delete a context is feasible.
If, however, you have responsibilities for a large deployment of Tomcat servers, or just a Tomcat server running in a high volume environment, the game changes fundamentally. You will need something that allows for "on-the-fly" changes, and more importantly, you need a clear separation between server configuration parameters shared by all applications, and configurations for each individual web application. Although there are merits in keeping all configuration in one place, when you are pressed for time, you don't want to wade through an ultra-long configuration file to get at the parts you want to change or delete. I learned that painful lesson when adding a CD-RW drive to a running web server recently.
So, thanks go out to Josh for his suggestions. I have changed the section on web application deployment, and I must say that overall, it all makes more sense now.