« Previous | 1 | 2 | 3 | Next »

Tomcat - Structure of the WebArchive

You develop your web application within a specifi ed directory structure so that it can be archived and deployed on Tomcat 7. All servlets, classes, static fi les, and other resources belonging to a web application are organized under a directory hierarchy. The root of this hierarchy defi nes the document root of your web application. All fi les under this root directory can be served to the client, except for fi les 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.

Always place private fi les (fi les which are not required to serve to the client) in the WEB-INF directory, under the root directory. All fi les under WEB-INF are private, and are not served to the client.

WebApplicationName/: In this directory (or a subdirectory), all the static fi les, such as HTML and JSP fi les 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 specifi c to the application are placed here.
/WEB-INF/classes: This contains all the server-side classes or your application-specifi c third-party classes.
/WEB-INF/lib: This directory contains JAR fi les used for the JSP completion.
web.xml: It contains the details of all your dynamic fi les (servlets and JSP) and also other confi guration-related information such as session time out and defi ning 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-name fi eld).

classB =new class.classB ()
<servlet-mapping>
<servlet-name> classB </servlet-name>

Archive Files

In most production environments, you receive a deployment unit as an archive fi le from the developer. An archive fi le is a single fi le that contains all of an application or module's classes, static fi les, directories, and deployment descriptor fi les. Archive fi les are typically created by using the JAR utility or Ant JAR tool.

Deployment units that are packaged using the JAR utility have a specifi c fi le extension depending on the type, as explained in the following points:

EJBs are packaged as .jar fi les
Web applications are packaged as .war fi les
Resource adapters are packaged as .rar fi les
Enterprise applications are packaged as .ear fi les, and can contain any combination of EJBs, web applications, and resource adapters
Web services can be packaged either as .ear fi les or as .war fi les

Exploded archive directories

An exploded archive directory contains the same fi les and directories as a JAR archive. However, the fi les and directories reside directly in your fi lesystem and are not packaged into a single archive fi le with the JAR utility.

A deployment unit should be deployed as an exploded archive directory, rather than a single archive fi le, 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.

It's not possible to edit deployment descriptor values in the console for deployments from the archive fi les or .war files.
You are deploying a web application that contains static fi les 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 fi les without re-creating the archive.

Deployment operations

The deployment tools provide support for performing these common deployment operations:

Deploy: It makes deployment source fi les 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 fi le 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.

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 fi les 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 fi les be available on the target servers as a result of an earlier deployment.
Undeploy: This stops a deployment unit and then removes its deployment fi les and the deployment name from the target servers.

An application becomes unavailable to clients during undeployment. 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.

« Previous | 1 | 2 | 3 | Next »

The largest Interview Solution Library on the web

Tomcat - Structure of the WebArchive