PQ67190: WEBSPHERE APP SER 4.0 AE INFOCENTER SECTION 6.5.1:HOT DEPLOYMENTAND DYNAMIC RELOADING IS FOR WAS AES AND HAS MULTIPLE MISTAKES.

APAR status
Closed as documentation error.

Error description
The WebSphere Application Server AE InfoCenter section 6.5.1 was
directly taken from the
AEs InfoCenter.  The behavior of AE and AEs are very different
and this page is almost totally incorrect.
Here are some observations:
War Files Section
-This section is basically correct except where it says "If
reloading is disabled,
the server will have to be restarted to detect the change."
This should be changed to "If reloading is disabled, the
Enterprise Application will have to be restarted to detect
the change."
EJB Jar Files Section
-This entire section needs to be readdressed.
Problems include the following:
1. DrAdmin cannot be used to restart modules; this feature
is not available in WebSphere Application Server AE.
2. Also after install it does not appear that the
ibm-ejb-jar-ext.xmi or
ibm-ejb-jar-bnd.xmi files are read again or updated during
console changes.
This information is instead placed directly into the
repository.
3. There does not appear to be any proven ability for EJBs
to be dynamically
deployed nor reloaded.
Application Section
-Also needs to be totally rewritten and some problems
currently include:
1. DrAdmin cannot be used to restart modules; this feature
is not available in WebSphere Application Serve AE.
2. Unsure whether updates to the xml files are automatically
picked up.
Server Configuration Section
-Problems include
1. Anytime server-cfg.xml is mentioned it is incorrect; AE does
not have this file.
2. Restart the server could be replaced with restart the
Enterprise Application
if the statement actually holds true
HTTP Plugin Configuration Changes:
1. These for the most part seem accurate.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server Version 4       *
*                 users of hot deployment and dynamic          *
*                 reloading.                                   *
****************************************************************
* PROBLEM DESCRIPTION: Updated information for WebSphere       *
*                      Application Server Version 4 InfoCenter *
*                      article 6.5.1: Hot deployment and       *
*                      dynamic reloading.                      *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
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
When modules of an application are installed on a server group
then the user actions mentioned below must be taken on all
nodes that run individual clones of the server group.

View information about updating and redeploying:

WAR Files
EJB Jar Files
Application
Server Configuration
HTTP Plugin Configuration Changes
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> name>.ear/<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> name>.ear/<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 enterprise application 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 <app name>.ear/<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. name>.ear/<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 enterprise application 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 /<app
name>.ear/<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. name>.ear/<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 enterprise application 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 name>.ear/<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. name>.ear/<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 enterprise application 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. administrative console or a wscp 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 You can use the
administrative console or a wscp 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.
administrative console or a wscp command.
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.
administrative console or a wscp command.
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 (This is
not working on the current driver)
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. administrative console or a wscp command.
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 Use the administrative console
or a wscp command 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
6.6.1.3.2: Starting and stopping enterprise applications (and
modules) with the Web administrative console
6.6.0.17: DrAdmin command reference
6.6.0.1.4: Starting and stopping resources with the Java
administrative console
Problem conclusion
Close this APAR as a documentation change.
Temporary fix Comments
APAR information
APAR number PQ67190
Reported component name WEBSPHERE AE NT
Reported component ID 5630A2201
Reported release 400
Status CLOSED DOC
PE NoPE
HIPER NoHIPER
Submitted date 2002-10-14
Closed date 2003-01-07
Last modified date 2003-04-30

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros

Fix information

Applicable component levels


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ67190
IBM Group: Software Group
Modified date: Apr 30, 2003