Accessibility
Icon or Spacer
   

Planning and Deploying Your J2EE Servlet/JSP Application

by Patrick Quinn
Consultant
Allaire Corporation

A critical part of the Java 2 Platform's Enterprise Edition (J2EE) standard is the specification for deploying applications in a consistent manner. JRun 3.0 leverages this powerful standard to allow developers to bring the advantages of sound planning and standards-based deployment to all of their production JRun applications.

Planning

Planning a production environment will necessarily be an application-specific task. Budgets, deadlines, scalability and security needs, and numerous other factors vary widely across projects, and planning must always conform to the particulars of those and other factors for any given project.

However, there are a couple of key steps to keep in mind when planning the production of your JRun application:

  1. Bypass JSP compilation.
  2. Explicitly map all servlets.

Bypassing JSP Compilation

JRun compiles a JavaServer Page (JSP) to create the page's CLASS file when the page is initially requested by a client and also when a requested JSP has been modified since its last request. However, in a production application, you may want to bypass compilation to force JRun to always load the page's CLASS file.

You bypass the compilation of a JSP for several reasons, including:

  • Performance: Compilation of static JSPs adds unnecessary processing overhead to your application.
  • Security: JSPs are text files that can be read and edited by anyone using the application. If you bypass JSP compilation, you do not need to ship the JSPs that make up the application; you instead ship only the corresponding CLASS files.

To explicitly disable JSP compilation, use the JRun Management Console (JMC) to modify the JRun servlet that handles JSPs. You make this setting at the Web application level so that you can enable or disable compilation for individual Web applications.

Use the following procedure to disable JSP compilation:

  1. In the JMC, select the server-name > Web Applications > app-name > Servlet URL mappings property. The corresponding form opens in the right side of the JMC.
  2. In the form, click the Edit button to open the Edit dialog box.
  3. Under the Virtual Path/Extension column, enter "*.jsp".
  4. Under Servlet Invoked, enter "jsprt".

The jsprt servlet will now be used to handle every request to a JSP. This servlet does not check for the existence of the JSP but instead looks only for the corresponding CLASS files. Therefore, in a deployed Web application, you do not need to actually deploy the JSPs. Because JSP files are source code files, you can omit your source code from deployed applications.

Disabling JSP compilation is a an optimization that you typically make only at application deployment time. With compilation turned off, you must ship the corresponding CLASS files for all JSPs. Therefore, you must precompile all JSP pages to create the CLASS files before you deploy the application. You perform precompilation in two ways:

  • With JSP compilation enabled, request every JSP in your application. Requesting the JSPs guarantees that every JSP has been compiled and has a corresponding CLASS file.

    The drawback to this method is that you must manually make the request of each JSP. Omitting a single JSP will cause an error if a client requests the page and the page has not been compiled.

  • Use the JSPC compiler to compile all JSPs from the command line. The JSPC compiler allows you to compile all JSPs associated with an application with a single command. This method guarantees to compile all JSPs.

To re-enable JSP compilation, use the following procedure:

  1. In the JMC, select the server-name > Web Applications > app-name > Servlet URL mappings property. The corresponding form opens in the right side of the JMC.
  2. In the form, click the Edit button to open the Edit dialog box.
  3. For the entry corresponding to jsprt, select Delete. JRun now uses the default servlet, jsp, to handle JSPs. This servlet recompiles any servlet whose modification time differs from that of the page's corresponding CLASS file.

Explicit Servlet Mappings for All Servlets

Explicit servlet mappings are defined and managed via the JMC and are maintained in the web.xml file. To maximize security, your production applications should define explicit servlet mappings for each servlet in your Web application. For information on defining servlet mappings through the JMC, see the JRun Setup Guide.

Deploying

As mentioned, JRun 3.0 is fully compliant with the J2EE standard and implements the Web application architecture described in the Servlet API Version 2.2 specification. Thus, deploying JRun 3.0 applications is a consistent process, regardless of project-specific factors.

Once you have developed and tested your application, the process for deploying it in a production environment varies depending on what components comprise your application. The following section describes the deployment steps for servlet/JSP applications.

Servlet/JSP Application Deployment

Typically, a Web application is distributed as a single compressed WAR file. The WAR file contains the complete directory structure and all files that define the application. You create a WAR file using the same tools that you use to create a JAR file.(Click here to read another article on deploying WAR files.)

Use either the JMC or the JRun deployment tool to deploy a WAR file, either of which accepts the WAR file and a set of server-specific parameters, expands the directory structure, and updates settings and property files, as needed.

During deployment, JRun explodes the WAR file and defines the new application in the specified JRun server. Exploding a WAR file is just JRun's mechanism for deployment.

The application assembler converts development output into a deployable Web application. Input to the Web application assembly process includes the following:

  • Java CLASS files for servlets, utilities, tag handlers, and TEI (Tag Extra Information) classes
  • Third-party classes and libraries
  • TLD (Tag Library Descriptor) files (if not contained in the tag library's JAR file)
  • The web.xml file
  • Application-specific properties files
  • Documentation, including JavaDocs and usage notes

Output from the application assembly process includes the following:

  • A WAR file
  • Installation notes
  • Configuration guidelines

Note: Don't forget to test the deployable WAR file thoroughly, using all supported combinations of hardware platform, operating system, Web server, and Java Virtual Machine (JVM).

Creating a WAR File

You create a WAR file using the Java jar utility. This utility has the following syntax:

jar options output-file input-files

Options

Options include one or more of the following:

  • c (create). Create the WAR file.
  • f (file). Create a file rather than direct to stdout.
  • v (verbose). Display file names as they are added to the WAR file.
  • 0 (zero). No compression.
  • M (manifest). Do not create the default manifest file.

Output-File

The output-file specifies the name of the file produced by the jar utility. Be sure to use the WAR suffix.

Input-files

This is a space separated list of files to add to the WAR file. Use the wildcard character (*) to add multiple files. If you specify any directories, the jar utility adds them recursively.

The following example creates a WAR file of the JRun default application (assuming a current directory of jruninstalldirectory/servers/default/default-app):

jar -cf default.war *.*

Deploying Web Applications

Deployers use the JRun deployment tool to install a Web application. You can use either the JMC or the command line interface.

The Web application deployment process involves the following:

  • Expanding the WAR file into a directory structure
  • Adding the Web application to a JRun server
  • Defining an application mapping for the Web application.

Before beginning the deployment process, you must know the following:

  • The location and full directory path of the WAR file.
  • The name of the JRun server to contain the deployed Web application.
  • The name of the Web application. JRun uses this name in the JMC and when outputting to the log.
  • The application hosts.
  • The URL prefix used by clients to access the Web application.
  • The full path of the directory into which the Web application is to be deployed. This directory must already exist. The deployment process will overwrite existing files with the same name.

Using the JMC

To deploy a Web application using the JMC, perform the following steps:

  1. Log on to the JMC.
  2. Click (don't expand) the server to which the Web application will be deployed.
  3. Click "Web Applications."
  4. In the right pane, click "Deploy an Application."
  5. Specify information.
  6. Click "Deploy."

Using the Command Line Interface

The command line interface to the Web application deployment tool allows you to deploy a WAR file using a set of parameters. The interface accepts parameters from a properties file and from the command line.

Syntax

The WarDeploy utility allows you to deploy, remove, and redeploy a Web application. It is contained in the jrun.jar file. Use the following syntax:

java allaire.jrun.tools.WarDeploy -deploy -config=deploy.properties
java allaire.jrun.tools.WarDeploy -remove -config=remove.properties
java allaire.jrun.tools.WarDeploy -redeploy -config=remove.properties

Property File Format

The deploy.properties file contains the following:

  • deploy.war.path=full path to .war file
  • deploy.server.name=default | servername
  • deploy.webapp.name=application name
  • deploy.context.path=/context path
  • deploy.webapp.rootdir=web application root directory (full path)
  • deploy.jrun.rootdir=JRun root directory (full path)

The following sample shows a deploy.properties file:

deploy.war.path=c:\\testdeploy\\rds-app.war
deploy.server.name=default
deploy.webapp.name=testdeploy
deploy.context.path=/testdeploy
deploy.webapp.rootdir=c:\\testdeploy
deploy.jrun.rootdir=c:\\program files\\allaire\\jrun

Note: You must escape slashes in a pathname, '\', in this file with a second slash, '\\'.