2EE developers working in a standard lifecycle model often face challenges in managing deployment descriptors for the different lifecycle stages. In larger J2EE development environments where IT governance is an issue, developers follow a strict process of promoting their J2EE applications through a standard lifecycle model from development to testing and finally to production. The challenge is deployment descriptors are unique to the web server to which they are deployed. If the development, test and production web servers are configured differently, then developers must create unique .wars and .ears for each web server used in the lifecycle.

There's a sensible reason why Web servers are often configured differently: unique database names for each stage of the lifecycle. Something as simple as a unique database name for each environment requires the J2EE developer to rebuild his J2EE components using a different deployment descriptor for each web server in the lifecycle. This means that instead of building a single .war or .ear that is moved across the lifecycle, the developers must build three versions: one for development, one to be executed in testing, and one for production release. And we all know that rebuilding an object after it has been tested is risky; how do you guarantee that only the deployment descriptors were changed between the testing and production versions of the .wars an .ears?

I have learned through experience the importance of carefully managing these files from the development to production lifecycle. If you release a "development" version of the deployment descriptor onto a production server, chances are that your evening will be consumed with the tedious task of sorting out why the application ran in development, but died in testing—or worse, died in production.

If you don't quite understand why these files could cause such an immediate production headache, consider the following: A deployment descriptor can be understood by comparing an .ear file to a .zip file. Imagine that you have a .zip file containing 1,000 files. You want to copy that .zip file to five different locations, but first you must change some of the text in 10 of the zipped-up files, and the changes are different for each location where you need a copy. This task requires recreating the .zip file by uniquely configuring the 10 text files and re-zipping them five times. Then you copy each .zip file to the correct location according to the changes made. Basically, this is the exact process required for deploying a J2EE application to an enterprise environment where multiple server configurations are required.

It is important to keep in mind that the use of multiple deployment descriptors is not a deployment or coding problem. It is a "build" problem.

As mentioned earlier, the most common scenario requires a minimum of three deployment descriptors for a single database-connected J2EE application. For example, your database may be named "DEV-DB" in development, "QA-DB" in testing, and "PROD-DB" in production, each of which requires its own version of the .ear or .war file. But in many cases the changes between the deployment descriptors go far beyond the name of the database.

This problem is not entirely the fault of the J2EE specifications, but largely the result of increased use of third-party modules and interconnectivity of enterprise applications and services. A single application running on a production server may require parameters that specify multiple database connections, log file locations, message queues, security information, CICS regions, and other server-specific information. Put that same application on a second production server for a different business unit and all of these values could be different. It is not unusual to see applications where as many as 100 values change. If you're doing parallel development with multiple production, test, and/or development servers, the problem compounds rapidly. When this is the case, for obvious reasons, you want to know that the correct version of the .ear or .war is being deployed to the correct server.

Solve the Problem at the Build Level
It is important to keep in mind that the use of multiple deployment descriptors is not a deployment or coding problem. It is a "build" problem. I hear far too often companies looking for a "deployment" solution because they continually make the mistake of deploying incorrect .wars and .ears to web servers. Automating your deployment process will simply allow you to more quickly deploy the wrong .war or .ear. It is in the creation of the .wars and .ears during the "build" process that must be addressed.

When building .wars and .ears from within an IDE, the IDE allows you to configure a deployment descriptor for a single web server. Through the IDE you enter all of the unique web server configuration data and the IDE does the rest. This process works well for development, but is inefficient when attempting to support multiple .wars and .ears for test and production. This is because developers must stop working on the development level of code, and rebuild an older version of the .war or .ear, which can make it difficult to ensure that only the test or production level of code was used to create the corresponding version of the .war or .ear.

Because IDEs do not handle the creation of multiple deployment descriptors for multiple configurations, when it comes time to promote the application to the next stage of the lifecycle, developers must consider more efficient, less error-prone ways to get the job done.

There are basically two options. The easiest option is to consider the use of an enterprise build management tool that can handle the creation of multiple .wars and .ears. The market for enterprise build management tools is just beginning to emerge. Don't rule out the use of a commercial build tool just because you believe you can write scripts to get the job done. Commercial build tools offer many benefits such as footprinting, impact analysis, remote build scheduling and monitoring. These features are not so easy to script. By using a commercial tool, you solve your J2EE build headaches and gain many new features that can assist you in your development and release process. If a commercial tool is not an option, then you will need to develop your own build process using scripts.

Editor's Note: The author is President and CTO of Catalyst Systems, a vendor of commercial build tools. We have selected this article for publication because we believe it to have objective technical merit. No specific editorial product endorsement is implied.

Establishing an improved build process for your J2EE applications first requires a close look at exactly how your .ears and .wars are assembled. Planning is essential at this stage. If you choose to write a solution in-house, you should be prepared to perform Perl and Ant/XML scripting, and of course documentation and training for all developers who will be involved in the final assembly process. Also, you can expect to deal with the pains of trial and error before coming up with the correct solution that works for your organization.