Resources

SAS® AppDev Studio™ 3.0 Developer's Site

Deploying Web Applications

This page provides general information about Web application deployment. Information relating to specific application servers or servlet containers can be found at the following locations:

Tomcat Deployment Information
WebLogic Deployment Information

Production Server Requirements

Before you deploy your Web application, make sure that your production environment meets the AppDev Studio requirements. Basically, you can deploy to any application server and/or servlet container that provides full support for the Servlet 2.3/JSP 1.2 standard using JDK 1.4.0 or higher. In addition, the SAS server that you access from your Web applications must include the AppDev Studio Server-Side updates. For complete details on the server-side requirements for both Web servers and SAS servers, see the AppDev Studio Requirements.

General Deployment Process

Overview

The following provides a short checklist of steps that you need to take to deploy Web applications developed with AppDev Studio. It is not meant to be a comprehensive list; the remaining sections of this document provide the details you need. Instead, this section serves as a quick reference to help make it easy to deploy Web applications.

  1. Choose the form of deployment, WAR file or source directory, if supported. If a WAR file, also choose, if necessary, whether the Web application will be served in expanded form or directly from the WAR file.

  2. Determine if any changes to the Web application are needed to account for switching environments from development to production, and how those changes will be handled. For example, it may be necessary to modify which SAS servers are accessed by the Web application.

  3. Prepare WAR file or copy Web application source directory to deployment location, if necessary.

  4. Deploy the Web application to application server or servlet container.

  5. Update the application server or servlet container with any settings needed by the Web application.

  6. Start or restart the Web application or server, as needed.

  7. Test the deployed Web application to ensure the deployment was successful.

It is best if these items are considered when development of a Web application begins and during development. This will help avoid deployment surprises and having your choices limited. These items are discussed in more detail in the sections that follow.

Choosing the form of deployment

Using a WAR file is the typical way to deploy the Web application's content. It involves a single file and is supported by the Servlet specifications. The specifications also support serving the Web application directly from the WAR file. However, this isn't required. When serving a Web application in an expanded form, the specifications don't require the expanded form look like the WAR directory structure, though it is likely to be similar or identical.

Thus, it is best to develop the Web application such that it can be served directly from the WAR file. If this isn't feasible, then you should verify what the expanded form looks like on your expected target application servers or servlet containers. You would also have the option of using the source directory form of deployment, if supported.

If you plan to have a Web application served from a WAR file, make sure you avoid the use of ServletContext.getRealPath() and ServletRequest.getRealPath(). Both of these methods will return null when the Web application is served from a WAR file.

Determine if changes are needed to switch to production

It is likely that any SAS servers accessed by a Web application during development will need to change when it is deployed to the production environment. What needs to change depends on how the server locations are built into the web application. Such settings could be in properties files or the web.xml file in some fashion. If you are using SAS Foundation Services, switching to the production version of the services metadata source will likely involve additional changes.

How the settings are implemented can impact the choices available to implement the changes. For example, the application server or servlet container may allow modifying web.xml settings after the Web application is deployed. It might also be feasible to implement the settings using System properties. This might avoid making changes to the Web application just prior to deployment, but may dictate that the application server or servlet container may need to be restarted to have new System properties take effect.

If making changes just prior to deployment can't be avoided, switching might be automated using Ant or some other build tool. If using webAF, see the documentation on Standard and Custom Build Tasks to see what might be done to automate this in webAF's build script.

Prepare the WAR file or copy the Web application source directory

If deploying a WAR file, make any pre-deployment changes that are needed. Then prepare a JAR archive of the Web application's root directory using ".war" as the file extension. The files in the root directory of the Web application should appear in the WAR file with no relative path. The web.xml file should in the WAR file with a relative path of WEB-INF.

WebAF provides an Ant task for creating a WAR file. Execute Build [arrow] Project Tasks [arrow] package-war to create the WAR file. The WAR file will be in the project directory of the Web application project and have the same name as the project.

Note that the webAF package-war task in the project's build file excludes Java source files, Build Frame servlet FML files, and component palette support MTL files, i.e. ".java", ".fml", and ".mtl" files, respectively. These files may be present during the development of the Web application by webAF, but are unnecessary in the deployed Web application. Also note that this task includes validating the web.xml file. If any warnings or errors occur, the WAR file is not created. You must make any corrections necessary so that the web.xml validates successfully before the WAR file can be created. For information on dealing with such errors, see Troubleshooting web.xml Errors.

If working outside of webAF, automating the creation of the WAR file is easily accomplished using Ant. You can also use the Jar utility supplied with the JDK, though excluding files is not as easily accomplished. If possible, you should validate the web.xml prior to creating the WAR file.

If deploying the Web application source directory, copy it to the appropriate location. You can make any necessary changes to the copy, including removal of any ".java", ".fml", and ".mtl" files, if desired.

Deploy the Web application to the application server or servlet container

Use the application server or servlet container specific procedure to deploy the WAR file or source directory. If deploying a WAR file, note that it is not typically required that the context name under which the Web application is served match the name of the WAR file. However, when using automated procedures, the WAR file name will be used as the content name by default. If this matters, modify the WAR file name to the desired context name prior to deployment. When using automated procedures with a source directory, it might be necessary to modify the name of the subdirectory holding the Web application content to obtain the desired context name.

Update application server or servlet container settings

This step involves applying any needed changes to the application server or servlet container settings to account for the addition of the Web application. If necessary, the minimum and maximum heap sizes should be adjusted. If the Web application creates lots of transient objects, garbage collection options may need to be tuned. The changes might also include adding runtime permissions required by the Web application, and if appropriate, enabling a security manager, if not already enabled.

There might also be post-deployment Web application changes needed. For example, depending on the Web application's memory consumption and its anticipated user load, an adjustment to the session timeout might be in order. There could also be additional Web application settings specific to the application server or servlet container that need setting or adjusting.

Start or restart the Web application or server

Depending on what changes were required in the prior step, the actions necessary to get the Web application running correctly should be one of the following:

The specifics of performing any of the actions above will depend on the application server or servlet container being used.

Test the deployed Web application

As always, thoroughly testing the deployed Web application is necessary to verify the deployment was successful. This includes verifying that the Web application can access all of the required SAS servers and spawners. You must also make sure that any required updates have been applied to the SAS servers.

You should also inspect the application server or servlet container's status information or log files to see if anything unusual occurred. The Servlet 2.3 specifications do not clearly define what should happen if problems are encountered during deployment and startup of the Web application. For example, if during Web application startup, the class for a filter declared in the web.xml fails to load, it isn't specified whether the Web application should be allowed to run without this filter or prevented from running. Behavior in a case like this could vary.