+

Search Tips   |   Advanced Search

Hot deployment and dynamic reloading

We can make various changes to applications and their modules without having to stop the server and start it again. Making these types of changes is known as hot deployment and dynamic reloading.

The following note applies to the xmi file references in this topic:

For IBM extension and binding files, the .xmi or .xml file name extension is different depending on whether we are using a pre-Java EE 5 application or module or a Java EE 5 or later application or module. An IBM extension or binding file is named ibm-*-ext.xmi or ibm-*-bnd.xmi where * is the type of extension or binding file such as app, application, ejb-jar, or web. The following conditions apply:

However, a Java EE 5 or later module can exist within an application that includes pre-Java EE 5 files and uses the .xmi file name extension.

The ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, and ibm-portlet-ext.xmi files continue to use the .xmi file extensions.

This topic assumes that the application files are deployed on a server and we want to upgrade the files.

See Ways to update enterprise application files and determine whether hot deployment is the appropriate way for you to update our application files. Other ways are easier and hot deployment is appropriate only for experienced users.

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. Changes that we make to the application files using hot deployment are not recognized by administrative console or wsadmin application management functions. Those functions recognize only the application files that administrative programs such as the console or wsadmin present during application installation, update or other management functions. The application management functions do not recognize files changed by hot deployment.

Important: 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 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.

Hot deployment is the process of adding new components (such as WAR files, EJB Jar files, enterprise Java beans, servlets, and 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:

As opposed to the changes made to a deployed application described in Update enterprise application files, changes made using hot deployment or dynamic reloading do not use the administrative console or a wsadmin scripting command. We 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, we must restart the server after updating the application.

(Solaris) (HPUX) Restriction: The hot deployment and dynamic reloading function is not supported when the product is running on these operating systems. The JAR files within the associated Java Development Kit (JDK) are memory mapped. If these JAR files are updated by the hot deployment and dynamic reloading functionality when they are being used by the Java virtual machine (JVM), the files become inconsistent, which results in an application server crash. When we make changes to an application on these operating systems, do not use the hot deployment and dynamic reloading functionality. Instead, restart the application to reflect the changes.


Hot deployment and dynamic reloading

  1. Locate your expanded application files.

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

      app_server_root/installedApps/cell

    Your EAR file...

      ${APP_INSTALL_ROOT}/cell/application_name.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 WAS 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 the application. If we 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/application_EAR_name/deployments/application_name/

    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.

    Important: 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 we 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 us to quickly change application files; it does not support the full management lifecycle of an application.

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

  3. Required: If we are running WAS on a group of machines using WAS ND and we 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 we run WAS on a group of machines using WAS ND and we 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 WAS ND 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 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 JSP files in a web module, a web container reloads JSP files 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.

    Restart enterprise applications provides information on using the administrative console to start, stop, or restart an application.

    Starting applications and Stopping applications 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.

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 administrative 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, your manual changes to an application in the installedApps directory are not exported. To export those changes, we must copy and move the application files manually.


Subtopics


Related:

  • Configuration documents
  • Update enterprise application files