InfoCenter Home >
6: Administer applications >
6.5: Maintaining and updating applications >
6.5.1: Hot deployment and dynamic reloading

6.5.1: Hot deployment and dynamic reloading

This article outlines the types of changes that can be made to application servers and their contents with respect to hot deployment and dynamic reloading. In other words, it discusses what you can change, and how, without having to stop the server and start it again.

Hot deployment is the process of adding new components (such as enterprise 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

View information about updating and redeploying:

WAR Files

Change an existing JSP File

  • User Action: None
  • Comments: The changed JSP can be placed directly in the product_installation_root/installedApps/<app name>/<module name> directory, or the appropriate subdirectory. The change will be automatically detected and the JSP will be recompiled and reloaded.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Add a new JSP File to an existing application

  • User Action: None
  • Comments: The new JSP can be placed directly in the product_installation_root/installedApps/<app name>/<module name> directory, or the appropriate subdirectory. The new file will be automatically detected and compiled on the first request to the page.
  • Hot deployment: Yes
  • Dynamic reloading: Yes
Change an existing Servlet class (edit and recompile)

  • User Action: None (if reloading is enabled). If reloading is disabled, the server will have to be restarted to detect the change.
  • Comments: The new version of the servlet .class file can be placed directly in the product_installation_root/installedApps/ <app name>/<module name>/WEB-INF/classes directory. If the .class file is part of a jar file, the new version of the jar file can be placed directly in product_installation_root/installedApps/<app name>/<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.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Change a dependent class of an existing Servlet class

  • User Action: None (if reloading is enabled). If reloading is disabled, the server will have to be restarted to detect the change.
  • Comments: The new version of the dependent .class file can be placed directly in the product_installation_root/installedApps /<app name>/<module name>/WEB-INF/classes directory. If the .class file is part of a jar file, the new version of the jar file can be placed directly in product_installation_root/installedApps/<app name>/<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.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Add a new Servlet using the Invoker (Serve Servlets by class name) facility or add a dependent class to an existing application

  • User Action: None (if reloading is enabled). If reloading is disabled, the server will have to be restarted to detect the change.
  • Comments: The new .class file can be placed directly in the product_installation_root/installedApps/<app name>/<module name>/WEB-INF/classes directory. If the .class file is part of a jar file, the new version of the jar file can be placed directly in product_installation_root/installedApps/<app name>/<module name>/WEB-INF/lib. This case is treated the same as changing an existing class. The difference is that adding the servlet/class does not immediately cause the Web application to reload, since the class has never been loaded before. The class simply becomes available for execution.
  • Hot deployment: Yes
  • Dynamic reloading: Non-applicable
Add a new Servlet, including a new definition of the servlet in the web.xml deployment descriptor for the application

  • User Action: None (if reloading is enabled). If reloading is disabled, the server will have to be restarted to detect the change.
  • Comments: The new .class file can be placed directly in the product_installation_root/installedApps/<app name>/<module name>/WEB-INF/classes directory. If the .class file is part of a jar file, the new version of the jar file can be placed directly in product_installation_root/installedApps/<app name>/<module name>/WEB-INF/ lib. The web.xml file can be edited in place or copied into the product_installation_root/installedApps/<app name>/<module name>/WEB-INF directory. The new .class file will not trigger a reload of the application. However, updating the web.xml file will cause the application to reload at the next reload interval. Once the reload is complete, the new servlet will be available for service.
  • Hot deployment: Yes
  • Dynamic reloading: Non-applicable
Modification to the web.xml file of an application

  • User Action: None (if reloading is enabled). If reloading is disabled, the server will have to be restarted to detect the change.
  • Comments: You can change most of the parameters of the web.xml file without restarting the server. However, there are exceptions:
    • <security-constraints> A security constraint of the application
    • <security-role> Security roles that you can change, add, or delete
    • <login-config> The login config values

    To change the listed properties, you must restart the module using the DrAdmin command.

  • Hot deployment: Yes
  • Dynamic reloading: Yes
Modification to the ibm-web-ext.xmi of an application

  • User Action: None (if reloading is enabled). If reloading is disabled, the server will have to be restarted to detect the change.
  • Comments: You can change all of the extension settings. The only warning is if you set the reloadInterval property to zero (0) or you set reloadEnabled property to false, the application will reload once at the time of the change. However, after this final reloading, the Web module will no longer detect any changes of any kind. Both of these changes disable the reloading function. The only way to re-enable reloading and the Dynamic functions is to change the appropriate property and restart the module using the DrAdmin command.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Modification to the ibm-web-bnd.xmi of an application

  • User Action: Restart the Module
  • Comments: You can use the DrAdmin command to restart a module of the application. The bindings will be reloaded at that time.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes

EJB Jar Files

Modification to ejb-jar.xml of an application

  • User Action: Restart the Module
  • Comments: You can use the DrAdmin command to restart a module of the application. The changes will be reloaded at that time.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Modification to ibm-ejb-jar-ext.xmi

  • User Action: Restart the Module
  • Comments: You can use the DrAdmin command to restart a module of the application. The changes will be reloaded at that time.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Modification to ibm-ejb-jar-bnd.xmi

  • User Action: Restart the Module
  • Comments: You can use the DrAdmin command to restart a module of the application. The changes will be reloaded at that time.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Modification to Table.ddl for an EJB Jar

  • User Action: Rerun DDL file on user database server
  • Comments: This change really has no effect on the application server and is a change to the database table schema for the EJBs
  • Hot deployment: Non-applicable
  • Dynamic reloading: Non-applicable
Modification to the Map.mapxmi file for an EJB Jar

  • User Action: Redeploy the EJB and restart the module
  • Comments: A change to this file requires you to regenerate the deployed code artifacts for the EJB, apply the new EJB jar to the server and restart the module using the DrAdmin program.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Modification to the Schema.dbxmi file for an EJB Jar

  • User Action: Redeploy the EJB and restart the module
  • Comments: A change to this file requires you to regenerate the deployed code artifacts for the EJB, apply the new EJB jar to the server and restart the module using the DrAdmin program.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Update the Implementation class for an EJB or a dependent class of the implementation class for an EJB

  • User Action: Restart the Module and/or Application.
  • Comments: After changing the Jar/Class File in the installedApps folder, you must restart the module or application that the EJB is part of. You should restart the application if other modules in the application use the changed module. If the changed module is used by modules in other applications, you should restart those applications/modules.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Update the Home/Remote interface class for an EJB

  • User Action: Redeploy the EJB and restart the application
  • Comments: A change in the interfaces of the EJB requires you to regenerate the deployed code artifacts for the EJB, apply the new EJB jar to the server and restart the application that the EJB jar is a part of. This will always work as long as you are using Module or Application visibility for class loading on the server.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Add a new EJB to a running server

  • User Action: Apply the new Jar to the installedApps folder and restart the application using the DrAdmin program.
  • Comments: This scenario assumes that the EJB is part of an existing EJB Jar file.
  • Hot deployment: Yes
  • Dynamic reloading: Yes

Application

Modification to the application.xml for an application

  • User Action: Restart the Application
  • Comments: The application must be restarted with the DrAdmin program.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Modification to the ibm-app-ext.xmi file for an application

  • User Action: Restart the Application
  • Comments: The application must be restarted with the DrAdmin program.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Modification to the ibm-app-bnd.xmi file for an application

  • User Action: Restart the Application
  • Comments: The application must be restarted with the DrAdmin program.
  • Hot deployment: Non-applicable
  • Dynamic reloading: Yes
Modification to a non-module Jar contained in the EAR

  • User Action: Restart the application
  • Comments: Use the DrAdmin tool to restart the application containing the Jar that has changed
  • Hot deployment: Yes
  • Dynamic reloading: Yes
Add a new EJB module to an existing, running application

  • User Action: Restart the server
  • Comments: Because adding a new module requires a change to server-cfg.xml, the server must be restarted to pick up the change.
  • Hot deployment: No
  • Dynamic reloading: No
Add a new Web module to an existing, running application

  • User Action: Restart the server
  • Comments: Because adding a new module requires a change to server-cfg.xml, the server must be restarted to pick up the change.
  • Hot deployment: No
  • Dynamic reloading: No
Addition of new application to server-cfg.xml of running server

  • User Action: Restart the server
  • Comments: Because adding a new application requires a change to server-cfg.xml, the server must be restarted to pick up the change.
  • Hot deployment: No
  • Dynamic reloading: No

Server Configuration

Modification to server-cfg.xml file of running server

  • User Action: Restart the server
  • Comments: Any change to server-cfg.xml requires the server to be restarted to pick up the change.
  • Hot deployment: No
  • Dynamic reloading: No

HTTP Plugin Configuration Changes

Modifications to application.xml to change the context root of a war file

  • User Action: Generate the Plugin config file through the Web-browser admin or through the GenPluginCfg.bat/sh script.
  • Comments: None
  • Hot deployment: Yes
  • Dynamic reloading: Yes
Modifications to web.xml to add, remove, or modify a servlet mapping

  • User Action: Possibly must re-generate the http plugin configuration file through the Web-browser admin or through the GenPluginCfg.bat/sh script.
  • Comments: If the Web application has file serving enabled or has a servlet mapping of '/', you do not have to regenerate the plugin configuration. In all other cases the regeneration is required.
  • Hot deployment: Yes
  • Dynamic reloading: Yes
Modification to server-cfg.xml to add, remove, or modify a HTTP transport, to add or remove a Virtual Host, or to add, remove, or modify a Virtual Host alias

  • User Action: Generate the Plugin config file through the Web-browser admin or through the GenPluginCfg.bat/sh file.
  • Comments: Any of these changes affect the plugin-cfg.xml file and require you to regenerate that file.
  • Hot deployment: Yes
  • Dynamic reloading: Yes
Go to previous article: Maintaining and updating applications Go to next article: Tools and resources quick reference

 

 
Go to previous article: Maintaining and updating applications Go to next article: Tools and resources quick reference