Prepare for application update settings
- Overview
- Replace the entire application
- Replace or add a single module
- Replace or add a single file
- Replace, add, or delete multiple files
Overview
To update enterprise applications, modules or files already installed on a server, from the console, go to...
- Applications > Application Types > WebSphere enterprise applications > [application|module] > Update
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 to be updated
Name of the installed (or deployed) application that we selected on the Enterprise applications page.
Replace the entire application
Under Application update options, specifies to replace the application already installed on the server with a new (updated) enterprise application .ear file.
After selecting this option, do the following:
- 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.
On multiple-server installations, using Remote file system we 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, .sar, 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 might be...
-
app_server_install_root/installableApps/test.ear
If we are installing a stand-alone WAR module, then specify the context root as well.
Tip: 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 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.
- If we are installing a stand-alone web application (WAR) or a SIP module (SAR), specify the context root of the WAR or SAR file.
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.
- 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.
Replace or add a single module
Under Application 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), SIP module (.sar 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 previous description of Replace the entire application .
To replace a module, the specified relative path (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 specified relative path must not match the path of a module in the installed application. The value specifies the desired path for the new module.
If we are installing a stand-alone web or SIP 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.
Next, specify whether to show only installation options that require you to supply information or to show all installation options.
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 product 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 the product 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.
Replace or add a single file
Under Application 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, .sar, .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 Replace the entire application option. To update a .war file, .sar file, .rar file, or .jar file that is defined as a module in the application, use the Replace or add a 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 Replace the entire application.
For the relative path (module URI), specify a relative path to the file that starts 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.
To replace a file, the relative path must match the relative path of the file to be updated in the installed application.
To add a new file to the installed application, the specified relative path must not match the relative path of an already existing file in the installed application. The value specifies the desired path for the new file.
After we specify the file system and relative paths, click Next.
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 product 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.
Replace, add, or delete multiple files
Under Application 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 we are uploading a compressed file and remote browsing only works for .ear, .sar, .war or .jar files. Specify a valid compressed file format, such as .zip. The path provides the location of the compressed file before installation. This option extracts 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, at any archive scope specify metadata in the compressed file using a file named...
-
META-INF/ibm-partialapp-delete.props
...which 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.jsp 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 we specify a file system path, click Next.
After a partial application update, when configuration changes are saved, the new or updated application file is stored in the deployed application in the WebSphere Application Server 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.
An example of entries in a partial application compressed file follows:
util.jar ETA-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...
- META-INF/ibm-partialapp-delete.props contains .*.dat and tools/test.jar files.
- webmod.war/META-INF/ibm-partialapp-delete.props contains 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.
Escape regular expression metacharacters in the META-INF/ibm-partialapp-delete.props file. For example, to delete inner classes for a class named Abc, use the regular expression Abc\$.* where $ is a regular expression metacharacter that is escaped with a backslash (\).
A META-INF/ibm-partialapp-delete.props file might contain the following text:
.*.dat webmod.war/META-INF/ibm-partialapp-delete.props: com/test/.*.jsp WEB-INF/test.xmi
Related: