java - How to provide a context configuration for a web application in Tomcat?

Question

I have a web application that relies on some resources and parameters to be configured after it is installed, like a JDBC connection.

What I have come up with is providing a META-INF/context.xml which is copied into [engine-name]/[server-name]/[app-name].xml by Tomcat when I deploy the application. This way all I am providing is a war file that can be copied into the appBase folder (webapps). Tomcat's documentation says if there is such a file it won't be overwritten which is really great, since the changes made after deployment won't be lost.

But there is a subtle issue here: Since we deploy the application by copying into webapps directory, Tomcat will first uninstall the existing application as well as the configuration file. This way the configuration file will be lost / overwritten which is not desirable. Tomcat won't modify this behaviour as far as I know.

The question is: Is there a way to work around this issue by installing the application in a way that Tomcat won't remove the existing configuration file. Or, is there a better way of packaging the application?

Please note that we don't want to set autoDeploy to false and we cannot use human intervention for the installation (which rules out using Tomcat Manager web application).

If I get the configuration file out of .war file and copy it separately as [engine-name]/[server-name]/[app-name].xml, Tomcat will still associate it with my application and remove it once I copy a new .war file.

Another assumption is: We don't know in advance the values to the configuration. We will only provide a sample configuration (a placeholder, if you wish) while actual configuration will be performed at some time later (not necessarily in the installation time).

Thanks

Answer 1

The solution is simple: don't put configuration in your context.xml.

Here is a solution that we use (which works well for a number of diverse external customers):

We have a single war which will be used in multiple environments, webapp.war. We have three environments, development, integration and production. Integration and production are at the customer site. We don't know passwords and file paths for the client integration and production sites.

We use a combination of two things: JNDI lookup for database stuff and external properties files.

In the context.xml that is delivered in the war, we have a ResourceLink

<ResourceLink name="jdbc/webapp"
     global="uk.co.farwell.webapp.datasource.MySqlDataSource" />

This gives a reference to a globally defined data source, which is defined in the server.xml for Tomcat.

<Resource auth="Container" 
          driverClassName="com.mysql.jdbc.Driver" 
          name="uk.co.farwell.webapp.datasource.MySqlDataSource" 
          password="xxx" url="xxx" username="fff" />

So the database details can be changed by editing the server.xml without changing the webapp.war. Crucially, this only needs to be done once for each server, not at redeploy.

In our spring configuration, to define the dataSource we have:

<jee:jndi-lookup id="dataSource" jndi-name="jdbc/webapp" />

For other properties, we have a global application.properties file which is delivered along with the webapp.war, but is not part of the war. This is referenced by a -D on the command line to start Tomcat. -Duk.co.farwell.webapp.applicationDir="/usr/xxx/fff". We pick up the definition and read the properties file. The database stuff could be done this way as well, but we'd lose the pooling done by Tomcat.

Another thing: we don't have to rebuild if servers are moved, or if machines are changed for some reason. This is a matter for the customer and their infrastructure people.