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
The following note applies to the xmi file references in this topic:
Supported configurations: For IBM® extension and binding files, the
.xmi or
.xml file name extension is different depending on whether you 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:
- For an application or module that uses a Java EE version
prior to version 5, the file extension must be .xmi.
- For an application or module that uses Java EE 5 or
later, the file extension must be .xml. If .xmi files are
included with the application or module, the product ignores the .xmi
files.
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.
Restriction: The hot deployment and dynamic reloading function
is not supported when the product is running on these operating systems. The Java archive (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 you 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.
This topic assumes that your application files are deployed on a server and you 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 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 enterprise application files, 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 WebSphere Application Server Network Deployment and you are changing an application on a
particular node, disable automatic synchronization.
-
Click 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 WebSphere Application Server 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 WebSphere Application Server 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.
-
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.