Hot deployment and dynamic reloading

 

+

Search Tips   |   Advanced Search

 

Overview

Hot deployment allows one to add new components (WAR files, EJB Jar files, enterprise Java beans, servlets, JSP files, etc...) to a running appserver without having to cycle the application appserver process.

Dynamic reloading allows one to change an existing component without needing to cycle the appserver in order for the change to take effect.

If the application you are updating is deployed on a appserver that has its application class loader policy set to Single, you might not be able to dynamically reload the application. At minimum, restart the appserver after updating the application.

Do not use hot deployment to update components in a production deployment manager managed cell. Hot deployment is well-suited for development and testing, but poses unacceptable risks to production environments. Full or partial resynchronization might erase hot deployed components. Further, hot deployed components are not migrated between versions of WebSphere Application Server. To add new components or modules to an enterprise application, reassemble the application EAR file so it has the new components or modules and then redeploy the EAR file.

  1. Locate the expanded application files. The application files are in the directory specified when installing the application or, if you did not specify a custom target directory, are in the default target directory...

    install_root/installedApps/cell

    ...the EAR file...

    ${APP_INSTALL_ROOT}/cell/appname.ear

    points to the target directory. The variables.xml file for the node defines ${APP_INSTALL_ROOT}.

    It is important to locate the expanded application files because, as part of installing applications, a WebSphere application appserver unjars portions of the EAR file onto the file system of the computer that will run the application. These expanded files are what the appserver looks at when running the application.

    If you cannot locate the expanded application files, look at the binariesURL attribute in the deployment.xml file for the application. The attribute designates the location the run time uses to find the application files.

    For the remainder of this information on hot deployment and dynamic reloading, application_root represents the root directory of the expanded application files.

  2. Locate application metadata files. The metadata files include the deployment descriptors (web.xml, application.xml, ejb-jar.xml, and the like), the bindings files (ibm-web-bnd.xmi, ibm-app-bnd.xmi, and the like), and the extensions files (ibm-web-ext.xmi, ibm-app-ext.xmi, and the like).

    Metadata XML files for an application can be loaded from one of two locations. The metadata files can be loaded from the same location as the application binary files (such as application_root/META-INF) or they can be loaded from the WebSphere configuration tree,

    ${CONFIG_ROOT}/cells/cell/applications/EAR_file/deployments/appname/

    The value of the useMetadataFromBinary flag specified during application installation controls which location is used. If specified, the metadata files are loaded from the same location as the application binary files. If not specified, the metadata files are loaded from the application deployment folder in the configuration tree.

    For the remainder of this information, metadata_root represents the location of the metadata files for the specified application or module.

  3. CAUTION: If you are running WebSphere Application Server on a group of machines using Network Deployment and you are changing an application on a particular node, disable automatic synchronization.

    1. Click System Administration > Node Agents in the administrative console navigation tree, click on a node agent name, and then click File Synchronization Service.

    2. On the File Synchronization Service page, remove the checkmark from the check box for Automatic Synchronization and click OK.
    When you run WebSphere Application Server on a group of machines using Network Deployment and you change a file on the disk in the expanded application directory for a particular node, you can lose those changes the next time node synchronization occurs. In the Network Deployment environment, the configuration stored by the deployment manager is the master copy and any changes detected between that master copy and the copy on a particular machine trigger the master copy to be downloaded to the node.

  4. (Optional)   Examine the values specified for Reload Enabled and Reload Interval on the settings page for the 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 the Web module's extended deployment descriptors in an assembly tool.

  5. Change or add the following components or modules as needed:

  6. For changes to take effect, you might need to start, stop, or restart an application. "Starting and stopping applications" provides information on using the administrative console to start, stop, or restart an application. "Example: Starting an application using wsadmin" and "Example: Stopping running applications on a appserver using wsadmin" provide information on using the wsadmin scripting tool.

  7. If you disabled automatic synchronization in step 3, return to the File Synchronization Service page, enable Automatic Synchronization, and click OK.
Related concepts
Configuration documents
Related tasks
Installing a new application