Prepare for application update settings

Use this page to update enterprise applications, modules or files already installed on a server.

To view this administrative console page, do the following:

  1. Click Applications > Enterprise Applications.

  2. Select the installed application or module that you want to update.

  3. Click Update.

Clicking Update displays a page that helps you update application files deployed in the cell. We can update the full application, a single module, a single file, or part of the application. If a new file or module has the same relative path as a file or module already existing on the server, the new file or module replaces the existing file or module. If the new file or module does not exist on the server, it is added to the deployed application.

Application name

Name of the installed (or deployed) application that you selected on the Enterprise Applications page.

Full application

Under Update options, specifies to replace the application already installed on the server with a new (updated) enterprise application .ear file.

After selecting this option, specify whether the .ear file is on a local or remote file system and the full path name of the application. The path provides the location of the updated .ear file before installation.

Use Local file system if the browser and the updated files or modules are on the same machine, whether or not the server is on that machine too. Local file system is available for all update options.

Use Remote file system if the application file resides on any node in the current cell context. 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. Also use the Remote file system option to specify an application file already residing on the machine running the application server. For example, the field value on a Windows machine might be C:\WebSphere\AppServer\installableApps\test.ear.

Note: During application installation, 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.

After specifying the required information on the .ear file, click Next to display a wizard for updating application files. The update wizard, which is similar to the installation wizard, provides fields for specifying or editing application binding information. Complete the steps in the update wizard as needed.

When the full application is updated, the old application is uninstalled and the new application is installed. When the configuration changes are saved and subsequently synchronized, the application files are expanded on the node where application will run. If the application is running on the node while it is updated, then the application is stopped, application files are updated, and application is started.

Single module

Under Update options, specifies to replace a module in or add a module to an installed application. The module can be a Web module (.war file), enterprise bean module (EJB .jar file), or resource adapter module (connector .rar file).

After selecting this option, specify whether the module is on a local or remote file system and the full path name of the module. The path provides the location of the updated module before installation. For information on Local file system and Remote file system, refer to the description of Full application above.

To replace a module, the value for Relative path to module (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. The context root is combined with the defined servlet mapping (from the .war file) to compose the full URL that users type to access the servlet. For example, if the context root is /gettingstarted and the servlet mapping is MySession, then the URL is http://host:port/gettingstarted/MySession.

After specifying the required information on the module, click Next to display a wizard for updating application files. The update wizard, which is similar to the installation wizard, provides fields for specifying or editing module binding information. Complete the steps in the update wizard as needed.

After a single module is added or updated, when configuration changes are saved, the new or updated module is stored in the deployed application in the WAS configuration repository. When these changes are synchronized with the node, the module is added or updated to the node's file system. If the application is running on the node when the module is added or updated, then one of the following occurs:

  • For updates to a Web module, the running Web module is stopped, Web module files are updated, and then the Web module is started.

  • For module additions, the added module is started on the application servers where the application is running after it is expanded on the node. An application restart is not necessary.

  • If the class loader policy for the application is set to Single so that all modules share a class loader, then the entire application is stopped and restarted for module level changes.

  • If the security provider configured with WebSphere Application Server does not support dynamic updates, then the entire application is stopped and restarted for module level changes.

  • For all other updates to a module, the entire application is stopped, the module files are updated, then the entire application is started.

Single file

Under Update options, specifies to replace a file in or add a file to an installed application.

Use this option to update a file used by the application that is not an .ear, .war, .rar or, in some instances, a .jar file. Use this option to add or update .jar files that are not defined as modules in the application. To update an .ear, file use the Full application option. To update a .war file, .rar file , or .jar file that is defined as a module in the application, use the Single module option.

After selecting this option, specify whether the file is on a local or remote file system and the full path name of the file. The path provides the location of the updated file before installation. For information on Local file system and Remote file system, refer to the description of Full application above.

Next, specify a value for Relative path to file. The relative path of the file must start from the root of the .ear file. For example, if the file is located at com/company/greeting.class in module hello.jar, specify a relative path of hello.jar/com/company/greeting.class.

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.

After a single file is added or updated, when configuration changes are saved, the new or updated file is stored in the deployed application in the WebSphere Application Server configuration repository. When these changes are synchronized with the node, the file is added or updated to the node's file system. If the application is running on the node when the file is added or updated, then one of the following occurs:

  • When files are added at application metadata scope (META-INF directory) or updated at any application scope or in non-Web modules, the entire application is stopped, the file is added or updated, and then the entire application is restarted.

  • When files are added at application non-metadata scope (outside of META-INF directory but not in any module), the changes are saved in the file system without restarting the running application.

  • When files are added or updated to Web module metadata (META-INF or WEB-INF directory), the running Web module is stopped, the Web module file is added or updated, and then the Web module is started.

  • For all other files in Web modules, the file is added or updated on the node's file system without stopping the application or any of its components.

Partial application

Under Update options, specifies to update 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.

After selecting this option, specify whether the compressed file is on a local or remote file system and the full path name of the compressed file. You will likely use Local file system because you are uploading a compressed file and remote browsing only works for .ear, .war or .jar files. 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.

Use Local file system if the browser and the updated files or modules are on the same machine, whether or not the server is on that machine too. Local file system is available for all update options.

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.

The relative path of a file in the installed application is formed by concatenation of the relative path of the module (if the file is inside a module) and the relative path of the file from the root of the module separated by /.

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.

Level of files to delete Metadata .props file to include in compressed file
Application Include META-INF/ibm-partialapp-delete.props in the compressed file. In the metadata .props file, list files to be deleted. File paths are relative to the location of the META-INF/ibm-partialapp-delete.props file.

For example, to delete a file named utils/config.xmi from the root of the my.ear file, include the line utils/config.xmi in the META-INF/ibm-partialapp-delete.props file.

Module Include module_uri/META-INF/ibm-partialapp-delete.props in the compressed file.

To delete one file from a module, include the file path relative to the module in the metadata .props file. For example, to delete a/b/c.jsp from the my.jar module, include a/b/c.class in my.jar/META-INF/ibm-partialapp-delete.props file in the compressed file.

To delete multiple files within a module, list the files to be deleted in the metadata .props file with one entry on each line. For example, to delete all JavaServer Pages (.jsp files) from the my.war file, include the line .*jsp in the my.war/META-INF/ibm-partialapp-delete.props file. The line uses a regular expression, .*jsp, to identify all .jsp files in my.war.

Use a single partial application file to add, delete and update multiple files.

After a partial application update, when configuration changes are saved, the new or updated application file is stored in the deployed application in the WAS configuration repository. When these changes are synchronized with the node, the files are added or updated to the node's file system. Because the partial application option updates multiple files, the application components that are restarted are determined using individual files in the partial application.

 

Example

An example of entries in a partial application compressed file follows: 

util.jar
META-INF/ibm-partialapp-delete.props
foo.jar/com/mycomp/xyz.class
xyz.war/welcome.jsp
xyz.war/WEB-INF/web.xml
webmod.war/META-INF/ibm-partialapp-delete.props

For this example, the META-INF/ibm-partialapp-delete.props file contains the .*.dat and tools/test.jar files. The webmod.war/META-INF/ibm-partialapp-delete.props file contains the com/test/.*.jsp and WEB-INF/test.xmi files.

The partial application update option does the following:

  • Adds or replaces util.jar in the deployed application.

  • Adds or replaces com/mycomp/xyz.class inside the foo.jar file of the deployed application.

  • Deletes *.dat files from the application, but not from any modules.

  • Deletes tools/test.jar from the application.

  • Adds or replaces welcome.jsp inside the xyz.war module of the deployed application.

  • Replaces WEB-INF/web.xml inside the xyz.war module of the deployed application.

  • Deletes com/test/*.jsp from the webmod.war module.

  • Deletes WEB-INF/test.xmi from the webmod.war module.

 

See Also


Enterprise (J2EE) applications

 

Related Tasks


Updating applications