We are currently running Tomcat 5.5.27 and have our context defined in META-INF/context.xml. We call Tomcat Manager through Ant to push changes from our development environment to a development server using the Tomcat Manager Deploy Ant task with update="true".
Now we want to move the Context configuration from META-INF/context.xml to server.xml so that we have all our Tomcat configuration in one spot. I have this working fine, but now when I try to run our Ant script I get the following from Tomcat Manager Deploy Ant task:
The only thing I can find that might explain it is Tomcat bug 34399, where it seems like undeploy is made to not work if the context is defined in server.xml, but works if context is defined in context.xml.
Does this seem like I'm on the right track, and we'll have to keep the context in META-INF/context.xml if we want to use the Tomcat Manager Ant tasks? Or am I missing something else?
Now we want to move the Context configuration from META-INF/context.xml to server.xml so that we have all our Tomcat configuration in one spot.
Do not do this!!!
Sorry to be so loud, but...
Putting context definitions in the server.xml has been discouraged since Tomcat4 and I don't care WHAT Eclipse WTP tries to do. Besides, if you want to use Tomcat's management webapps, you can't use them for server.xml redeployments.
If you put the context definitions in server.xml, they hold the entire server hostage. If you want a central location, look at TOMCAT_HOME/conf/Catalina/localhost. Although I believe that Tomcat will copy the context.xml into this directory, at least in some cases. Once there, the context in the conf/Catalina/localhost overrides whatever you have in the WAR itself.
Oh, and welcome to the JavaRanch!
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Apr 27, 2011
The one place that recommended putting Context config in server.xml is the O'Reilly Tomcat book. Their reasoning is that then all the config is in one place, and its not like you can get away with not editing server.xml anyway. But as I've been looking more and more at Tomcat configuration on the web, I've seen a lot of folks share your sentiments about breaking the Context configuration out of server.xml.
I'm just learning and don't have a strong conviction one way or another (although the desire to use the Tomcat Manager for deployment probably puts me in the context.xml camp), but what are the reasons for avoiding putting the context in server.xml? You mention that it would hold the entire server hostage. Could you expand on that? Are there other reasons for keeping the context definition out of the server.xml?
In order to configure a Context within Tomcat a Context Descriptor is required. A Context Descriptor is simply an XML file that contains Tomcat related configuration for a Context, e.g naming resources or session manager configuration. In earlier versions of Tomcat the content of a Context Descriptor configuration was often stored within Tomcat's primary configuration file server.xml but this is now discouraged (although it currently still works).
It's true that it's a rare installation that doesn't have some tweaking done to server.xml, but most of those tweaks are static and only done at rare intervals, such as for example, when changing the security domain or activating URL logging. Application contexts tend to be much more volatile.
And that's why server.xml is no longer "the" place to define application contexts. In order to get changes to server.xml to take effect, you have to shut down the entire Tomcat server, including unrelated webapps.
If you use the server context directory, that's not necessary. Change the context and the automatic scanning mechanism will redeploy the updated webapp and [i]only[i] the updated webapp, leaving the other webapps alone. In actual practice this often doesn't work in Tomcat 6, thanks to the infamous PermGen Space error, but in better-behaved versions, you can be a lot less disruptive.
As to whether keeping everything in one file - embedded alongside a lot of other information, including some that have security implications - I'm not sure that's such a great advantage. Then again, my production servers run Linux, and in linux, it's pathetically easy to stack up a one-line command sequence that can concatenate all the files in the context directory into one file, format them into a PDF, and email the PDF.