You can change Web application archives (WAR files) on application
servers without having to stop the server and start it again.
About this task
There are several changes that you can make to WAR files without
stopping the server and starting it again.
Important: See
Ways to update 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 run the wasadmin stopApplication and startApplication commands.
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 run the wasadmin stopApplication and startApplication commands.
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 run the wasadmin stopApplication and startApplication commands.
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 run the wasadmin stopApplication and startApplication commands.
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 run the wasadmin stopApplication and startApplication commands.
- 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.
- 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 run the wasadmin stopApplication and startApplication commands.