13.8.12 Settings for detecting updates and reloading the J2EE applications

If you want to replace a modified J2EE application and a running J2EE application when testing during application development and during system operations, you can replace the applications by using the reload functionality. When a file configuring an exploded archive-format J2EE application is updated, you can reload the updated J2EE application by using update detection and command execution. By using the reload functionality, the J2EE application is replaced dynamically using fewer steps.

This subsection describes the settings for detecting updates and reloading the exploded archive-format J2EE applications. For details on the commands and file keys, see the uCosminexus Application Server Command Reference Guide and uCosminexus Application Server Definition Reference Guide.

The settings required for reloading an exploded archive-format J2EE application differ depending on whether the application is reloaded by detecting the configuration file updates or whether the application is reloaded by executing commands. The following table describes the settings required for reloading the exploded archive-format J2EE applications.

Table 13-17 Settings required for reloading

SettingsTo reload by detecting updatesTo reload by using commands
Setting the scope for the reload functionalityYY
Setting the update detection intervalY--
Setting the interval for configuration file updateY--
Settings for delayed reloadingY--
Changing the directory for storing the session information fileRR
Settings for JSP pre-compilationRR
Settings for monitoring the J2EE application execution timeRR
Legend:
Y: Settings are specified
R: Settings are specified as and when required
--: Not applicable

Organization of this subsection
(1) Setting the scope for the reload functionality
(2) Setting the update detection interval
(3) Setting the interval for configuration file update
(4) Settings for delayed reloading
(5) Changing the output destination of the session information file
(6) Settings for JSP pre-compilation
(7) Settings for monitoring the J2EE application execution time

(1) Setting the scope for the reload functionality

Specify the settings for the scope of the reload functionality in the <configuration> tag of the logical J2EE server (j2ee-server) in the Easy Setup definition file.

By default, the reload functionality is disabled. To use the reload functionality, you must enable the reload functionality and set the scope.

Note that the enabling or disabling of the reload functionality is decided based upon the combination of the scope of the local call optimization functionality specified in the ejbserver.rmi.localinvocation.scope parameter of usrconf.properties and the scope of the reload functionality. For details on the mapping between the scope of the local call optimization functionality and the scope of the reload functionality, see 13.8.2 Scope of reloading.

(2) Setting the update detection interval

Specify the settings for the update detection interval in the <configuration> tag of the logical J2EE server (j2ee-server) in the Easy Setup definition file. The following table describes the settings for the update detection interval specified in the Easy Setup definition file.

Table 13-18 Settings for the update detection interval in the Easy Setup definition file

Specified parametersSettings
ejbserver.deploy.context.check_intervalSpecify the interval (seconds) for monitoring the J2EE application configuration file and detecting the updates.
webserver.context.check_intervalSpecify the interval (seconds) for monitoring the Web application configuration file and detecting the updates.
webserver.jsp.check_intervalSpecify the interval (seconds) for monitoring the JSP configuration file and detecting the updates.

The relationship between the setup values of the update detection interval is as follows:

For EJB applications
The value in ejbserver.deploy.context.check_interval is used. Note that if 0 is specified in ejbserver.deploy.context.check_interval, the updates are not detected for EJB applications.
For the servlets
The value in webserver.context.check_interval or ejbserver.deploy.context.check_interval is used. The priority is as follows:
  1. Value in webserver.context.check_interval
  2. Value in ejbserver.deploy.context.check_interval
Note that if webserver.context.check_interval is not specified, the value in ejbserver.deploy.context.check_interval is used.
Also, if 0 is specified in webserver.context.check_interval, the updates are not detected for the servlets.
For the JSPs
The value in webserver.jsp.check_interval or ejbserver.deploy.context.check_interval is used. The priority is as follows:
  1. Value in webserver.jsp.check_interval
  2. Value in ejbserver.deploy.context.check_interval
Note that if webserver.jsp.check_interval is not specified, the value in ejbserver.deploy.context.check_interval is used.
Also, if 0 is specified in webserver.jsp.check_interval, the updates are not detected for the JSPs.

(3) Setting the interval for configuration file update

Specify the interval for configuration file update in the <configuration> tag of the logical J2EE server (j2ee-server) in the Easy Setup definition file. The following table describes the settings for the configuration file update interval specified in the Easy Setup definition file.

Table 13-19 Settings for the configuration file update interval in the Easy Setup definition file

Specified parametersSettings
ejbserver.deploy.context.update.intervalSpecify the time (seconds) required for copying the J2EE application configuration file.
webserver.context.update.intervalSpecify the time (seconds) required for copying the Web application configuration file.
webserver.jsp.update.intervalSpecify the time (seconds) required for copying the JSP configuration file.

The relationship between the setup values of the interval for configuration file update is as follows:

For EJB applications
The value in ejbserver.deploy.context.update.interval is used.
For the servlets
The value in webserver.context.update.interval or ejbserver.deploy.context.update.interval is used. The priority is as follows:
  1. Value in webserver.context.update.interval
  2. Value in ejbserver.deploy.context.update.interval
If webserver.context.update.interval is not specified, the value in ejbserver.deploy.context.update.interval is used.
For the JSPs
The value in webserver.jsp.update.interval or ejbserver.deploy.context.update.interval is used. The priority is as follows:
  1. Value in webserver.jsp.update.interval
  2. Value in ejbserver.deploy.context.update.interval
If webserver.jsp.update.interval is not specified, the value in ejbserver.deploy.context.update.interval is used.

(4) Settings for delayed reloading

Specify the settings for delayed reloading in the following parameter in the <configuration> tag of the logical J2EE server (j2ee-server) in the Easy Setup definition file:

(5) Changing the output destination of the session information file

When the Web applications are reloaded, the session information generated before reloading is inherited and used even after reloading. The session information is output to the session information file.

Output destination of the session information file
By default the session information file is output to the following locations:
  • In Windows
    Cosminexus-installation-directory\CC\server\repository\ server-name\web\context-root-name\cjwebsession.dat
  • In UNIX
    /opt/Cosminexus/CC/server/repository/server-name/web/context-root-name/cjwebsession.dat
Directory name for the Web applications
The name of the directory for the Web applications follows the rules based on the context root name. If the context root name contains a forward slash (/), dollar sign ($), percent sign (%), and plus sign (+), these signs are converted to the following characters:
Character before conversionCharacter after conversion
/$2f
$$24
%$25
+$2b
The context root name directory that forms the output destination is created when the Web application starts. However, if the context root is the root context, the context root of the output destination directory is created as $2f. The created directory is deleted when the Web application is terminated.

To change the output destination of the session information file, specify the settings in the Easy Setup definition file. Specify the following parameter in the <configuration> tag of the logical J2EE server (j2ee-server):

(Example) Example of settings for the output destination of the session information file

<configuration>
<logical-server-type>j2ee-server</logical-server-type>
<param>
<param-name>ejbserver.deploy.session.work.directory</param-name>
<param-value>C:\tmp\session_work</param-value>
</param>
:
</configuration>

In this example, the session information file of a Web application with the context root name 'examples' is output to the following location:
C:\tmp\session_work\web\examples\cjwebsession.dat

(6) Settings for JSP pre-compilation

Even when a class file generated from a JSP file using JSP pre-compile is updated, the update of the J2EE application configuration file is detected and the reload functionality is executed.

When you execute the JSP pre-compile functionality by specifying the -jspc option in the cjstartapp command, you must set up the JSP working directory using usrconf.properties. For details on the JSP pre-compile settings, see 2.5.8 Settings in the execution environment (J2EE server settings) in the uCosminexus Application Server Web Container Functionality Guide.

Note that when you use the cjjspc command to execute JSP pre-compile during application development, specify the details such as the JSP working directory in the command options. For details on using the cjjspc command for JSP pre-compilation, see 2.5 JSP pre-compile functionality and the storage of the compilation results in the uCosminexus Application Server Web Container Functionality Guide.

(7) Settings for monitoring the J2EE application execution time

When a configuration file update is detected, the reload processing starts when the processing of the requests being processed is complete, but if the processing of requests being processed is not over at this point, you can start the reload processing by implementing the method timeout and method cancellation functionality for the monitoring of the J2EE application execution time.

As and when required, you specify the settings for monitoring the J2EE application execution time. For details on the settings for monitoring the J2EE application execution time, see 5.3.9 Settings in the execution environment in the uCosminexus Application Server Operation, Monitoring, and Linkage Guide.