You 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. This topic assumes that your application files are deployed on a server and you want to upgrade the files.
See Ways to update application files and determine whether hot deployment is the appropriate way for you to update your application files. Other ways are easier and hot deployment is appropriate only for experienced users.
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.
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 Updating J2EE applications, 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.
The application files are in the directory you specified when installing the application or, if you did not specify a custom target directory, are in the default target directory, app_server_root/installedApps/cell_name. Your EAR file, ${APP_INSTALL_ROOT}/cell_name/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 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 you 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.
For the remainder of this information on hot deployment and dynamic reloading, application_root represents the root directory of the expanded application files.
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_name/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.
For the remainder of this information, metadata_root represents the location of the metadata files for the specified application or module.
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.
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 JavaServer Pages 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. You can set jspReloadingEnabled to true when editing your Web module's extended deployment descriptors in an assembly tool.
Starting or stopping J2EE applications provides information on using the administrative 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.
Because you directly
manipulated the application files on the server, you might not be able to
later use the administrative console or a wsadmin scripting command to work
with the files. For example, if you 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, copy and move the application
files manually.