Updating applications

You can update application files deployed on a server.

Refer to Ways to update application files and decide how to update your application files. You can update enterprise applications or modules using the administrative console or a wsadmin tool. Both ways provide identical updating capabilities. Further, in some situations, you can update applications or modules without restarting the application server.

Note that Version 6 supports Java 2 Platform, Enterprise Edition (J2EE) 1.4 enterprise applications and modules. If you are deploying J2EE 1.4 modules, ensure that the target server and its node support Version 6. The administrative console Server collection pages show the versions for servers and cluster members . You can deploy J2EE 1.4 modules to Version 6.x servers or to clusters that contain Version 6.x cluster members only. You cannot deploy J2EE 1.4 modules to servers on Version 5.x nodes or to clusters that contain Version 5.x cluster members . Refer to Installable module versions for details.

This article describes how to update deployed applications or modules using the administrative console.

Updating consists of adding a new file or module to an installed application, or replacing or removing an installed application, file or module. After replacement of a full application, the old application is uninstalled. After replacement of a module, file or partial application, the old installed module, file or partial application is removed from the installed application.

1. Update your application or modules and reassemble them using an assembly tool. Typical tasks include adding or editing assembly properties, adding or importing modules into an application, and adding enterprise beans, Web components, and files.

2. Back up the installed application.

   1. Go to the Enterprise Applications page of the administrative console. Click Applications > Enterprise Applications in the console navigation tree.

   2. Export the application to an EAR file. Select the application you want uninstalled and click Export. Exporting the application preserves the binding information.

3. With the application selected on the Enterprise Applications page, click Update . The Preparing for application update page is displayed.

4. Under Specify the EAR, WAR or JAR module to upload and install :

   1. Ensure that Application name refers to the application to be updated.

   2. Under Update options , select the installed application, module, or file that you want to update. The online help Preparing for application update settings provides detailed information on the options. Briefly, the options are as follows:

      Full application

      Replaces the installed (old) application with the updated (new) application on the server. If you select Full application , specify the path for the new .ear file. The path provides the location of the new .ear file before installation.

      Single module

      Adds a new module to, or replaces a module in, the installed application. Specify the path for the new Web module (.war), EJB module (.jar), or resource adapter module (.rar). The path provides the location of the new module before installation.

      To replace a module, the value for Relative path to module (or module URI) must match the path of the module to be updated in the installed application.

      To add a new module to the installed application, the value for Relative path to module must not match the path of a module in the installed application. The value specifies the desired path for the new module.

      If you are installing a standalone Web module, specify a value for Context root .

      Single file

      Adds a new file to, or replaces a file in, the installed application. Specify the path for the new file. The path provides the location of the new file before installation.

      To replace a file, the value for Relative path to file must match the path of the file to be updated in the installed application.

      To add a new file to the installed application, the value for Relative path to file must not match the path of a file in the installed application. The value specifies the desired path for the new file.

      The relative path to a file from the root of the application is the concatenation of the module path and the file path within the module. For example, if the file is com/mycompany/abc.class within the module foo.jar, then the relative file path is foo.jar/com/mycompany/abc.class.

      Partial application

      Updates multiple files of an installed application by uploading a compressed file. Depending on the contents of the compressed file, a single use of this option can replace files in, add new files to, and delete files from the installed application. Each entry in the compressed file is treated as a single file and the path of the file from the root of the compressed file is treated as the relative path of the file in the installed application.

      Specify a valid compressed file format such as .zip or .gzip. The path provides the location of the compressed file before installation. This option unzips the compressed file into the installed application directory.

      To replace a file, a file in the compressed file must have the same relative path as the file to be updated in the installed application.

      To add a new file to the installed application, a file in the compressed file must have a different relative path than the files in the installed application.

      To remove a file from the installed application, specify metadata in the compressed file using a file named META-INF/ibm-partialapp-delete.props at any archive scope. The ibm-partialapp-delete.props file must be an ASCII file that lists files to be deleted in that archive with one entry for each line. The entry can contain a string pattern such as a regular expression that identifies multiple files. The file paths for the files to be deleted must be relative to the archive path that has the META-INF/ibm-partialapp-delete.props file. Refer to Preparing for application update settings for more information.

   After you select an option, specify a path. Use Local file system if the browser and application files are on the same machine (whether or not the server is on that machine, too). Use Remote file system if the application file resides on any node in the current cell context. When Remote file system is specified, user profile QEJBSVR must have *R authority to the application file and at least *X authority to all directories in the path containing the file. You can browse the entire file system of a node if the node agent or deployment manager is running on that selected node. Only .ear, .jar, or .war files are shown during the browsing.

   During application updating, application files typically are uploaded from a client machine running the browser to the server machine running the administrative console, where they are deployed. In such cases, use the Web browser running the administrative console to select EAR, WAR, or JAR modules to upload to the server machine.

   In some cases, however, the application files reside on the file system of any of the nodes in a cell. To have the application server install these files, use the Remote file system option.

   Also use the Remote file system option to specify an application file already residing on the machine running the application server. For example, /QIBM/UserData/WebSphere/AppServer/V6/edition/profiles/default/installableApps/test.ear.. If you are installing a standalone WAR module, then specify the context root as well.

   After the application file is transferred, the Remote file system value shows the path of the temporary location on the deployment manager or server machine.

5. If you selected the Full application or Single module option:

   1. Click Next to display a wizard for updating application files.

   2. Complete the steps in the update wizard. This update wizard, which is similar to the installation wizard, provides fields for specifying or editing application binding information. Refer to information on installing applications and on the settings page for application installation for guidance. Note that the installation steps have the merged binding information from the new version and the old version. If the new version has bindings for application artifacts such as EJB JNDI names, EJB references or resource references, then those bindings will be part of the merged binding information. If new bindings are not present, then bindings are taken from the installed (old) version. If bindings are not present in the old version and if the default binding generation option is enabled, then the default bindings will be part of the merged binding information. You can select whether to ignore bindings in the old version or ones in the new version.

6. Click Finish .

7. If you did not use the Map modules to servers page of the update wizard, after updating the application, map the installed application or module to servers or clusters . Use the Map modules to servers page accessed from the Enterprise Applications page.

   1. Go to the Map modules to servers page. Click Applications > Enterprise Applications > application_name > Map modules to servers .

   2. Specify the application server where you want to install modules contained in your application and click OK . You can deploy J2EE 1.4 modules to servers on Version 6.x nodes or to clusters that contain cluster members on Version 6.x nodes only.

What to do next

1. If a changed application or module is deployed on a cluster, roll out the changes to all cluster members of the cluster on which the application or module is deployed. Click Rollout Update on the Enterprise Applications page to propagate the changed configuration on all cluster members of the cluster on which the application or module is deployed. Rollout Update sequentially updates the configuration on the nodes that contain
   cluster members.

   Tip: At the end of the Installing messages displayed by the console during application or module installation, click Manage Applications to go to the Enterprise Applications page. Do not save changes to your configuration until after you roll out the changes.

2. Save the changes to your configuration.

   In the Network Deployment product, after you click Save the old application files are deleted and new files are copied when the configuration on the deployment manager synchronizes with the configuration on the node where the application is installed.

   If the application is running when you update it, the application stops running before its files are copied to the destination directory of the node and restarts after the copy operation completes. Thus, the application is unavailable on the node during the time the node is synchronizing its configuration with the deployment manager.

3. Examine the values specified for Reload Enabled and Reload Interval on the settings page for your enterprise application.

   If reloading of application files is enabled and the reload interval is greater than zero (0), the application's files are reloaded after the application is updated. For Web modules such as servlets and JavaServer page (JSP) files, a Web container reloads a Web module only when the IBM extension reloadingEnabled in the ibm-web-ext.xmi file is also set to true. You can set reloadingEnabled to true when editing your Web module's extended deployment descriptors in an assembly tool.

4. If needed, restart the application manually so the changes take effect.

   If the application is updated while it is running, WebSphere Application Server automatically stops the application or only its changed components, updates the application logic, and restarts the stopped application or its components.

5. If the application you are updating is deployed on a server that has its application class loader policy set to Single, restart the server.

Related tasks
Deploying and administering applications
Getting started with scripting