Hot deployment and dynamic reloading


 

+

Search Tips   |   Advanced Search

 

Hot deployment is the process of adding new components to a running server without having to stop the appserver process and start it again.

Dynamic reloading is the process of changing an existing component without needing to restart the server in order for the change to take effect. Dynamic reloading involves:

See also: Ways to update enterprise application files.

Do not use hot deployment if we intend to...

Changes that you make to the application files using hot deployment are not recognized by admin console or wsadmin.

Use standard application installation to have Administrative programs recognize files.

Do not use hot deployment to update components in a production dmgr 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. Also, running the restoreconfig command might overwrite changes made to expanded application files. Further, hot deployed components are not migrated between versions of WAS. 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.

As opposed to the changes made to a deployed application described in Updating enterprise application files, changes made using hot deployment or dynamic reloading do not use the admin console or a wsadmin scripting command. You must directly manipulate the application files on the server where the application is deployed.

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

  1. Locate the expanded application files.

    Default target directory...

    APP_ROOT/installedApps/mycell

    The EAR file...

    ${APP_INSTALL_ROOT}/mycell/myapp.ear

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

    As part of installing applications, a WebSphere application server unjars portions of the EAR file onto the file system. These expanded files are what the server looks at when running the application. If we cannot locate the expanded application files, look at the binariesURL in deployment.xml, which designates the location the run time uses to find the application files.

  2. Metadata files include the deployment descriptors...

    • web.xml
    • application.xml
    • ejb-jar.xml

    ...bindings files...

    • ibm-web-bnd.xmi
    • ibm-app-bnd.xmi

    ...the extensions files...

    • ibm-web-ext.xmi
    • ibm-app-ext.xmi

    Metadata XML files for an application can be loaded from one of two locations.

    • APP_ROOT/META-INF
    • CONFIG_ROOT/cells/mycell/applications/myEAR/deployments/myapp/

    The value of the flag useMetadataFromBinary 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.

    We can have useMetadataFromBinaries=true, change an extracted copy of the application using hot deployment, and have the changes take effect at run time by following the procedure in this topic. However, changes that you make to the application files using hot deployment are not recognized by console or wsadmin application management functions. Those functions recognize only the original application files and not the files changed by hot deployment. Do not use hot deployment if we intend to export the application, generate a plug-in based on the application configuration, or perform other application management in the future. Hot deployment enables you to quickly change application files; it does not support the full management lifecycle of an application.

  3. Required: If running WAS on a group of machines using ND and we are changing an application on a particular node, disable automatic synchronization.

    1. Go to...

      System Administration > Node agents > node_agent_name > File synchronization service

    2. On the File synchronization service page, clear the check box for Automatic synchronization and click OK.

    When you run WAS on a group of machines using ND and you change a file on the disk in the expanded application directory for a particular node, we can lose those changes the next time node synchronization occurs. In the ND environment, the configuration stored by the dmgr 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. Examine the values specified for Reload classes when application files are updated and Polling interval for updated files on the settings page for the application's class loader.

    If reloading of classes is enabled and the polling interval is greater than zero (0), the application files are reloaded after the application is updated. For JSPs in a Web module, a Web container reloads JSPs only when the IBM extension jspReloadingEnabled in the jspAttributes of the ibm-web-ext.xmi file is set to true.

    We can set jspReloadingEnabled 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, we might need to start, stop, or restart an application.

    Start or stop enterprise apps provides information on using the admin console to start, stop, or restart an application.

    Starting applications with scripting and Stopping applications with scripting provide information on using the wsadmin scripting tool.

  7. If we disabled automatic synchronization in step 3, enable automatic synchronization again:

    1. Return to the File synchronization service page.

    2. Select Automatic synchronization.

    3. Click OK.

 

Results

The application files are updated on the server.

Because you directly manipulated the application files on the server, we might not be able to later use the admin console or a wsadmin scripting command to work with the files. For example, if we try exporting a manually changed application using Export on an Enterprise applications console page, the manual changes to an application in the installedApps directory are not exported. To export those changes, copy and move the application files manually.

 

Related concepts

Change application files
Change WAR files
Change EJB Jar files
Change the HTTP plug-in configuration
Configuration documents

 

Related tasks

Updating enterprise application files