Separate web.xml for development and production

My web.xml is different in devel and production environments. For example in development environment there is no need in security constraints.

Typically I deploy new application version as follows:

1. Export Eclipse project to WAR.
2. Upload WAR to the server.
3. Redeploy.

The problem is that I have to manually uncomment secur开发者_Go百科ity constraints in web.xml before exporting.

How do you solve this problem?

I also met an opinion in some articles that "web.xml is rarely changed". But how can web.xml not change if it is exported to WAR on every update?

Thanks in advance!

If you can't use the same web.xml during development, I would automate the build process, use two web.xml and bundle the "right" one at build time depending on the targeted environment as Brian suggested. But, instead of Ant, I'd choose Maven because it will require less work IMHO and it has a built-in feature called profiles that is perfect to manage environment specific stuff like here.

In other words, I'd put the build under Maven 2 and use a production profile containing a specific maven-war-plugin configuration to build a WAR containing a web.xml having the required security constraints. Another option would be to merge the development web.xml (cargo can do that) to add the security-constraints but this is already a bit more "advanced" solution (a bit more complex to put in place).

I would create a development and production deployment with different web.xml configs. Automate the building/maintenance of these via your build (Ant/Maven etc.) to keep control of the common elements required.

I had to solve this problem many times in the past, and ended up writing XMLTask - an Ant plugin which allows the modification of XML files without using normal text replacement (it's a lot clever than that) and without having to mess with XSLTs (it's a lot simpler than that). If you follow the above approach you may want to check this out. Here's an article I wrote about it.

Assuming that you're stuck with the idea of web.xml changing before deployment to production, then my likely approach would be to run the development web.xml through a simple XSL transform which "decorated" the web.xml with your production-only elements, such as security constraints. Assuming that you can hook this step into your build process, then the production-ready web.xml should appear during your export process.

However, it is generally a good idea not to have different web.xml across environments, it devalues your testing. Having the same value in all environments will reduce the risk of bugs appearing only in your production environment.

I converted my project to be built using ant. The starting point was just this build.xml http://tomcat.apache.org/tomcat-6.0-doc/appdev/build.xml.txt

The above build doesn't have the feature of copying in a different web.xml(based on e.g. a property set when building), but you'll learn how to do that when get a bit into ant, should be pretty easy.

As a nice side effect, deploying to a remote tomcat is now just a couple of clicks away from within Eclipse instead of Export->war and manually copying it to the server.

I would add the necessary infrastructure to allow a mechanical build, with ant or maven.

When THAT is done you can have your mechanical build create two targets, one for test and one for production.

You should however, strongly consider testing the same code as you have in production. You will be bitten otherwise.

I believe having a single war that works in multiple environments is a superior solution than baking a new one with a profile option per dev, qual, and prod. It is super annoying there is not a better mechanism to get an environment variables directly in web.xml without using a library like spring.

One solution to web.xml environment configuration given that your environment customization is related to filter init params, such as:

<filter>
    <filter-name>CAS Filter</filter-name>
    <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
    <init-param>
        <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
        <param-value>https://<foo>:8443/login</param-value>
        ...

The particular filter class referenced above (CASFilter) is public. This means you can extend it will a custom adapter that adds in your environment configuration. This allows you to stay out of that nasty web.xml file.