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