Network Deployment (Distributed operating systems), v8.0 > Administer applications and their environment > Deploy and administering enterprise applications > Update enterprise application files > Hot deployment and dynamic reloading
Change or adding WAR files
We can change web application archives (WAR files) on application servers without having to stop the server and start it again.
The following note applies to the file references with a .xmi extension in this topic:
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 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 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.
There are several changes that you can make to WAR files without stopping the server and starting it again.
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. We can use the update wizard of the admin 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 JSP 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 |
Procedure
- Change an existing 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 admin console to
restart the application. Or use the startApplication and stopApplication attributes of the AdminControl object with wsadmin.sh.
If automatic reloading is enabled, you do not need to take further action. Automatic reloading will detect the change.
- 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.
- 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 admin console to
restart the application. Or use the startApplication and stopApplication attributes of the AdminControl object with wsadmin.sh.
If automatic reloading is enabled, you do not need to take further action. Automatic reloading will detect the change.
- 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.
- 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 admin console to
restart the application. Or use the startApplication and stopApplication attributes of the AdminControl object with wsadmin.sh.
If automatic reloading is enabled, you do not need to take further action. Automatic reloading will detect the change.
- 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.
- 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.
We 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 admin console to restart the application. Or use the startApplication and stopApplication attributes of the AdminControl object with wsadmin.sh. After the application restarts, the new servlet is available for service.
- 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.
- 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 admin console to restart the application. Or use the startApplication and stopApplication attributes of the AdminControl object with wsadmin.sh.
- Edit the web.xml file in place or copy it into the metadata_root/module_name/WEB-INF directory.
- Change the ibm-web-ext.xmi file of a WAR file.
Edit the extension settings as needed. We 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.
We 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 admin console to restart the application. Or use the startApplication and stopApplication attributes of the AdminControl object with wsadmin.sh.
- Edit the bindings as needed.
We can change all of the values but ensure that the entities you are binding to are present in the configuration of the server.
Hot deployment and dynamic reloading
Start applications using wsadmin.sh
Stop applications using wsadmin.sh