You can change web application archives (WAR files) on
application servers without having to stop the server and start it
again.
About this task
The following note applies to the file references with
a .xmi extension 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.
sptcfg
There
are several changes that you can make to WAR files without stopping
the server and starting it again.
Important: See
Ways to update enterprise application files and determine whether hot deployment
is the appropriate way for you to update your WAR files. Other ways
are easier and hot deployment is appropriate only for experienced
users. You can
use
the update wizard of the administrative console to make the
changes without having to stop and restart the server.
The
following table lists the changes that you can make by manipulating
a WAR file on the server where the application is deployed. The table
also states whether you use hot deployment or dynamic reloading to
make the changes.
Procedure
- Change an existing JavaServer Pages (JSP) file.
Place the changed JSP file directly in the application_root/module_name directory
or the appropriate subdirectory. The change will be automatically
detected and the JSP will be recompiled and reloaded.
- Add a new JSP file to an existing application.
Place the new JSP file directly in the application_root/module_name directory
or the appropriate subdirectory. The new file will be automatically
detected and compiled on the first request to the page.
- Change an existing servlet class by editing and
recompiling.
- Place the new version of the servlet .class file
directly in the application_root/module_name/WEB-INF/classes directory.
If the .class file is part of a Jar file, you can place the
new version of the Jar file directly in application_root/module_name/WEB-INF/lib.
In either case, the change will be detected, the web application will
be shut down and reinitialized, picking up the new class.
- If automatic reloading is not enabled, restart the application.
Use the administrative console to restart the application. Or use the startApplication and stopApplication attributes
of the AdminControl object with the wsadmin tool.
If
automatic reloading is enabled, you do not need to take further action.
Automatic reloading will detect the change.
- Change a dependent class of an existing servlet
class.
- Place the new version of the dependent .class file
directly in the application_root/module_name/WEB-INF/classes directory.
If the .class file is part of a Jar file, you can place the
new version of the Jar file directly in application_root/module_name/WEB-INF/lib.
In either case, the change will be detected, the web application will
be shut down and reinitialized, picking up the new class.
- If automatic reloading is not enabled, restart the application.
Use the administrative console to restart the application. Or use the startApplication and stopApplication attributes
of the AdminControl object with the wsadmin tool.
If
automatic reloading is enabled, you do not need to take further action.
Automatic reloading will detect the change.
- Add a new servlet using the Invoker (Serve Servlets
by class name) facility or add a dependent class to an existing application.
- Place the new .class file directly in the application_root/module_name/WEB-INF/classes directory.
If the .class file is part of a Jar file, you can place the
new version of the Jar file directly in application_root/module_name/WEB-INF/lib.
In either case, the change will be detected, the web application will
be shut down and reinitialized, picking up the new class.
This
case is treated the same as changing an existing class. The difference
is that adding the servlet or class does not immediately cause the
web application to reload because the class has never been loaded
before. The class simply becomes available for execution.
- If automatic reloading is not enabled, restart the application.
Use the administrative console to restart the application. Or use the startApplication and stopApplication attributes
of the AdminControl object with the wsadmin tool.
If
automatic reloading is enabled, you do not need to take further action.
Automatic reloading will detect the change.
- Add a new servlet, including a new definition
of the servlet in the web.xml deployment descriptor for the
application.
- Place the new .class file directly in the application_root/module_name/WEB-INF/classes directory.
If the .class file is part of a Jar file, you can place the
new version of the Jar file directly in application_root/module_name/WEB-INF/lib.
You can edit the web.xml file in place or copy it
into the application_root/module_name/WEB-INF/classes directory.
The new .class file will not trigger a reloading of the application.
- Restart the application.
Use the administrative
console to restart
the application. Or use the startApplication and stopApplication attributes
of the AdminControl object with the wsadmin tool. After the application
restarts, the new servlet is available for service.
- Change the web.xml file of a WAR file.
- Edit the web.xml file in place or copy it into
the metadata_root/module_name/WEB-INF directory.
- Restart the application.
Use the administrative
console to restart
the application. Or use the startApplication and stopApplication attributes
of the AdminControl object with the wsadmin tool.
- Change the ibm-web-ext.xmi file of a
WAR file.
Edit the extension settings as needed. You
can change all of the extension settings. The only warning is if you
set the reloadInterval property to zero (0) or the reloadEnabled
property to false, the application no longer automatically
detects changes to class files. Both of these changes disable the
automatic reloading function. The only way to re-enable automatic
reloading is to change the appropriate property and restart the application.
See other task descriptions in this file for information on restarting
an application.
Deprecated feature: The reloadInterval and
reloadingEnabled attributes of the IBM deployment descriptor extensions,
including both the WAR file extension
WEB-INF/ibm-web-ext.xmi and
the application extension
META-INF/ibm-application-ext.xmi are
deprecated.
depfeat
- Change the ibm-web-bnd.xmi file of
a WAR file.
- Edit the bindings as needed. You can change all of the
values but ensure that the entities you are binding to are present
in the configuration of the server.
- Restart the application.
Use the administrative
console to restart
the application. Or use the startApplication and stopApplication attributes
of the AdminControl object with the wsadmin tool.