You can change Web application archives (WAR files) on application servers without having to stop the server and start it again.
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. In some situations, 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.
Change | Hot deployment | Dynamic reloading |
---|---|---|
Change an existing JavaServer Pages file. | Not applicable | Yes |
Add a new JSP file to an existing application. | Yes | Yes |
Change an existing servlet class by editing and recompiling. | Not applicable | Yes |
Change a dependent class of an existing servlet class. | Not applicable | Yes |
Add a new servlet using the Invoker (Serve Servlets by class name) facility or add a dependent class to an existing application. | Yes | Not applicable |
Add a new servlet, including a new definition of the servlet in the web.xml deployment descriptor for the application. | Yes | Not applicable |
Change the web.xml file of a WAR file. | Yes | Yes |
Change the ibm-web-ext.xmi file of a WAR file. | Not applicable | Yes |
Change the ibm-web-bnd.xmi file of a WAR file. | Not applicable | Yes |
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.
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.
If automatic reloading is enabled, you do not need to take further action. Automatic reloading will detect the change.
If automatic reloading is enabled, you do not need to take further action. Automatic reloading will detect the change.
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 enabled, you do not need to take further action. Automatic reloading will detect the change.
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.
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.
Use the administrative console to restart the application. Or use the startApplication and stopApplication attributes of the AdminControl object with the wsadmin tool.
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.
Use the administrative console to restart the application. Or use the startApplication and stopApplication attributes of the AdminControl object with the wsadmin tool.