Contrary to what many developers might assume, designing and building an application is only half the battle. When the application is finished, it must then be packaged and deployed into the target environment. Many applications are built and packaged with the intent of being installed into a customer’s production environment. For others, the target deployment environment is in-house. For web applications, fortunately, the work that has to be accomplished in either case is very similar.
Internal deployments may be less formal and less nerve-wracking. However, they still should be taken seriously and conducted in an efficient and professional manner. Whether the customer is a “real” customer or another department within the organization, an unprofessional deployment can leave a bad impression. Formalizing the packaging and deployment process allows developers to focus on building a quality application and spend less time worrying whether the application will install and run correctly when it’s finished.
This chapter discusses the best practices for packaging and deploying a Struts application, including coverage of what it takes to automate the build process for your environment. Special attention is given to Ant, the Java-based build tool available from Jakarta.
Applications need to be deployed to be useful. There’s really no point in developing an application that never gets deployed, although this occurs more often than you might think. The need for deployment is obvious, but what about packaging? Does every Struts application have to be packaged before it gets deployed? The short answer is yes. In this chapter, though, we’ll examine the long answer.
Before we get into the details of packaging and deploying Struts applications, let’s define exactly what these two concepts mean in the context of web applications that are built using the Struts framework. Although the two concepts are closely related, they are not the same thing.
Packaging a Struts application involves gathering all the files and resources that are part of the application and bundling them together in a logical structure. Many different types of resources are usually included in a Struts application, and all of these need to be bundled with the application. Some of the more common types of resources that can be packaged with a Struts application are:
HTML and/or XML files
Images, audio, and video files
Stylesheets
JavaServer Pages
Properties files
Java utility classes
Configuration files
ActionandActionFormclassesThird-party JARs
During the design stage, time and effort should be spent on deciding how you are going to structure the application. Not every detail needs to be figured out and resolved before construction begins, but you should understand the target environment’s requirements and how these requirements will affect your packaging and deployment strategy. Ideally, you should decide on the principal package and directory structure for the application before construction gets underway. This will help to alleviate the normal miscommunication between developers and reduce the number of redundant resource files.
As the previous section mentioned, packaging and deployment are closely related, but involve different tasks. While packaging determines where the resource files will reside in the package structure and how those resources will be bundled, deployment deals with how the bundled application will be installed and configured inside a target web container.
There are two approaches that you can use when deploying a web application into a container. The first approach is to deploy the web application in a web archive (WAR) file. Most web containers install a WAR file and make it available for users, often without even requiring a restart of the container. This approach is convenient because once the WAR file is properly built, the rest of the work is handled by the container. One of the downsides of this approach, however, is that if a change is made to any file or resource within the web application, a new WAR file must be created and redeployed into the container. The details of how to deploy your Struts application as a WAR file are discussed later in the chapter.
The second approach to deploying a Struts application puts more work on the developer. It still involves packaging your application as a WAR file, but includes manually unpackaging the WAR file into a directory of the container. The exact location of the directory is container-dependent. In Tomcat and Resin, for example, the default web applications directory is webapps. In the WebLogic application server, you have to unpack the WAR file underneath the applications directory. (All three of these containers also allow you to specify alternate installation directories.)
When expanding the WAR file, you need to create a directory into which to unpack the files. The name of the directory is usually the name of the web application. So for example, if the web application was called Storefront and you wanted to install it into Tomcat, you could create a directory called storefront under the webapps directory and unpack the WAR file there.
This deployment approach is referred to as an exploded directory format , because the WAR file is exploded back into its original structure within the container. The benefit of this approach over deploying the WAR file itself is that when there are changes, only the changed files need to be redeployed into the container. This is much easier when you’re still developing or debugging the application, but you may not want to leave it like this for production.
Tip
When deploying a web application into production, it’s a better approach to leave the WAR file packed because there’s less chance of one or more files getting contaminated. Leaving it as a single WAR file forces you to replace the entire WAR file if changes need to be made, so there’s no chance of a version of a file getting out of sync with the rest of the application.