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.
Before you begin
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 if you intend to export your application,
generate a plug-in based on the application configuration, or perform other
application management in the future. Changes that you make to your 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.
About this task
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:
- 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 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,
you must restart the server after updating your application.
Procedure
- Locate your expanded application files.
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.
- 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_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.
Important: You can have useMetadataFromBinaries=true,
change an extracted copy of your 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 your 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 you intend to
export your 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.
For the remainder of this information, metadata_root represents
the location of the metadata files for the specified application or module.
- Required: 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.
- Click System administration > Node agents > node_agent_name >
File synchronization service in the console navigation tree.
- On the File
synchronization service page, clear 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.
- Optional: Examine the values specified
for Reload classes when application files are updated and Polling
interval for updated files on the settings page for your 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 JavaServer Pages (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. You can set
jspReloadingEnabled to true when editing your Web module's extended
deployment descriptors in an assembly tool.
- Change or add the following components or modules as needed:
- For changes to take effect, you might need to start, stop, or restart
an application.
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.
- If you disabled automatic
synchronization in step 3, enable automatic synchronization again:
- Return to the File
synchronization service page.
- Select Automatic synchronization.
- Click OK.
Results
The application files are updated on the server.
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, you must copy and move the application
files manually.