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.
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
Java utility classes
Action and ActionForm classes
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 session.
The second approach to deploying a Struts application puts more work on the developer. It still involves packaging your applications 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 FirstStruts and you wanted to install it into Tomcat, you could create a directory called FirstStruts under the Webapps directory and unpack the WAR file there.
Note: The WAR file should not contain the FirstStruts directory as part of its structure.
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.
Packaging your Web applications using the WAR format is very convenient. The structure is precise, and because it is specified so carefully, porting your applications across the various Web containers is much easier.
Creating the WAR File
The first step in packaging your application as a WAR file is to create a root directory. In most cases, this directory will have the same name as your Web application. For our example, we will create a directory called FirstStruts.
After deciding how your JSP and HTML pages will be placed within your application, place them underneath the root directory in their appropriate subdirectories. For the FirstStruts example, our directory structure so far would look like following figure
The FirstStruts application directory structure
The next step in setting up the WAR file is to ensure that you have a WEB-INF directory underneath your root Web application directory. The WEB-INF directory contains all of the resources that are used internally by the application. For example, the TLD files for your custom tag libraries reside in this directory, as does the Web deployment descriptor. This is also where the Struts configuration files belong. No resource within this directory can be made public outside of the application.
Underneath the WEB-INF directory, create two subdirectories: one called classes and the other called lib. The classes directory should contain all of your utility and servlet classes. The lib directory should contain the JAR files that the application depends on.
Once all of the resources for the Web application are accounted for and are inside the appropriate directories, you need to use Java's archiving tool jar to package the directories and files. From a command line, change to the root directory of your Web application and use the jar utility. You need to give the file a .war extension, like this:
jar cvf FirstStruts.war .
As you changed to the root directory, the FirstStruts directory will not be included in the WAR file. This is fine, because you may want to call the root directory something else when it's installed. When you install the Web application, if you plan to explode the WAR file, all you need to do is create a directory and un-jar the files, like this:
C:\tomcat6.0\webapps>cp FirstStruts.war FirstStruts
C:\tomcat6.0\webapps\FirstStruts>jar xf FirstStruts.war
The location where the WAR file gets expanded is container-dependent. If you plan to distribute the WAR file without exploding it, all you have to do is place it in the appropriate place for the container. You don't have to recreate the FirstStruts directory, although you might want to delete the existing directory when deploying a newer version. Some containers are not good at removing old files before deploying an updated WAR file.
In most production environments, you receive a deployment unit as an archive file. An archive file is a single file that contains all of an application or module's classes, static files, directories, and deployment descriptor files. Archive files are typically created by using the jar utility or Ant or Maven tools.
Deployment units that are packaged using the jar utility have a specific file extension depending on the type
EJBs are packaged as .jar files.
Web Applications are packaged as .war files.
Resource Adapters are packaged as .rar files.
Enterprise Applications are packaged as .ear files, and can contain any combination of EJBs, Web Applications, and Resource Adapters.
Web Services can be packaged either as .ear files or as .war files.
You have to follow the following steps for deploying your application to Tomcat Server
Copy WAR file to " TOMCAT_HOME/Webapps/ "
Start the server from "TOMCAT_HOME/bin/startup. bat"
Access the application using URL "http://localhost:8080/application_Context_Name"
Weblogic Application Server
You have to follow the following steps for deploying your application to Weblogic Application Server
Start the server from "%WEBLOGIC_HOME%/user_projects/domains/%DOMAIN_NAME%/startWebLogic.cmd"
Create a WAR file. Put it in "%WEBLOGIC_HOME%/user_projects/domains/%DOMAIN_NAME%"
Access the application http://localhost:7001/application_Context_Name