Deployment is basically defined as the installation of the WAR files in the web application. In other words, we can define the unpacking of the WAR file in the Tomcat webapps directory.
You develop your web application within a specified directory structure so that it can be archived and deployed on Tomcat 7. All servlets, classes, static files, and other resources belonging to a web application are organized under a directory hierarchy. The root of this hierarchy defines the document root of your web application. All files under this root directory can be served to the client, except for files under the special directory WEB-INF, located under the root directory. The name of your web application is used to resolve requests for components of the application.
Note
Always place private files (files which are not required to serve to the client) in the WEB-INF directory, under the root directory. All files under WEB-INF are private, and are not served to the client.
- WebApplicationName/: In this directory (or a subdirectory), all the static files, such as HTML and JSP files are placed. This directory is the document root of your web application.
/WEB-INF/web.xml:It contains the deployment descriptor for the web application. Resources specific to the application are placed here./WEB-INF/classes:This contains all the server-side classes or your application-specific third-party classes./WEB-INF/lib:This directory contains JAR files used for the JSP completion.web.xml:It contains the details of all your dynamic files (servlets and JSP) and also other configuration-related information such as session time out and defining the datasource (access to DB).<servlet> <servlet-name>classB</servlet-name> <servlet-class>class.classB</servlet-class> </servlet>
In the previous snippet, we are mapping the name to the servlet class (when Tomcat 7 starts, it will create an object of the class and map it to the name we have provided in the
servlet-namefield).classB =new class.classB () <servlet-mapping> <servlet-name> classB </servlet-name>
In most production environments, you receive a deployment unit as an archive file from the developer. 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 JAR tool.
Deployment units that are packaged using the JAR utility have a specific file extension depending on the type, as explained in the following points:
- EJBs are packaged as
.jarfiles - Web applications are packaged as
.warfiles - Resource adapters are packaged as
.rarfiles - Enterprise applications are packaged as
.earfiles, and can contain any combination of EJBs, web applications, and resource adapters - Web services can be packaged either as
.earfiles or as.warfiles
An exploded archive directory contains the same files and directories as a JAR archive. However, the files and directories reside directly in your filesystem and are not packaged into a single archive file with the JAR utility.
A deployment unit should be deployed as an exploded archive directory, rather than a single archive file, in the following circumstances:
- You want to perform partial updates to a deployed application without redeploying the entire application.
- You want to use the Tomcat Manager to dynamically edit and persist selected deployment descriptor values for the deployment.
Note
It's not possible to edit deployment descriptor values in the console for deployments from the archive files or .war files.
- You are deploying a web application that contains static files that you will periodically update. In this case, it is easier to deploy the application as an exploded directory, because you can update and refresh the static files without re-creating the archive.
The deployment tools provide support for performing these common deployment operations:
- Deploy: It makes deployment source files available to target servers and loading classes into class loaders so that applications are available to clients.
- Redeploy: It updates a deployment unit or part of a deployment unit (for example, a WAR, a module within a WAR, or a static file in a Web Application) that is currently deployed and available to clients. When redeploying an entire application, all of the application's modules must redeploy successfully or the entire application is stopped.
Note
An application becomes unavailable to clients during redeployment. The Tomcat 7 server doesn't guarantee the operation of the application and deployment task if there is an access from the client at this time. For this reason, redeployment is not recommended for use in a production environment.
- Stop: This unloads an application's classes and makes an application unavailable to clients. Stopping still leaves the deployment files and deployment name available to the target servers for subsequent redeployment or starting.
- Start: It reloads an application's classes into class loaders and makes the application available to clients. Starting requires that the deployment files be available on the target servers as a result of an earlier deployment.
- Undeploy: This stops a deployment unit and then removes its deployment files and the deployment name from the target servers.