Hot deployment and dynamic reloading

 

+

Search Tips   |   Advanced Search

 

Overview

Hot deployment is the process of adding new components...

  • WAR files
  • EJB Jar files
  • enterprise Java beans
  • servlets
  • JSP files

...to a running server without having to stop the application server process and start it again.

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

  • Changes to the implementation of a component of an application, such as changing the implementation of a servlet

  • Changes to the settings of the application, such as changing the deployment descriptor for a Web module

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

If the application you are updating is deployed on a server that has its application class loader policy set to Single, you might not be able to dynamically reload your application. At minimum, restart the server after updating your 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. 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.

 

Procedure

  1. Locate your expanded application files.

    The application files are in the directory specified when installing the application,...

    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 server unjars portions of the EAR file onto the file system of the computer that will run the application. These expanded files are what the server looks at when running your application. If one cannot locate the expanded application files, look at the binariesURL attribute in the deployment.xml file for your application. The attribute designates the location the run time uses to find the application files.

  2. Locate application metadata files.

    The metadata files include...

    Deployment descriptors web.xml, application.xml, ejb-jar.xml
    Bindings files ibm-web-bnd.xmi, ibm-app-bnd.xmi
    Extensions files ibm-web-ext.xmi, ibm-app-ext.xmi

    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.

  3. If you are running WAS 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 | 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 Network Deployment and you change a file on the disk in the expanded application directory for a particular node, one 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. Examine the values specified for Enable class reloading and Reloading 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 files are reloaded after the application is updated. For Web modules such as servlets and 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. We can set reloadingEnabled to true when editing your 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 cycle the application.

  7. If you 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.

 

See also

Changing or adding application files
Changing or adding WAR files
Changing or adding EJB Jar files
Changing the HTTP plug-in configuration
Configuration documents
Installing application files with the console