+

Search Tips   |   Advanced Search

JavaServer Pages runtime reloading settings

JavaServer Pages files can be translated and compiled at run time when the JSP file or its dependencies are modified. This is known as JSP reloading. JSP reloading is enabled through the reloadEnabled JSP engine parameter in the WEB-INF/ibm-web-ext.xmi file: 

<jspAttributes xmi:id="JSPAttribute_1" name="reloadEnabled" value="true"/>
The following table contains reload settings for production and development environments.

  Settings
Configuration Attribute Production Environment Development Environment
reloadEnabled false true
reloadInterval n/a (ignored if reloadEnabled is false) approximately 5 seconds
trackDependencies n/a (ignored if reloadEnabled is false) true Alternatively, set this to false to improve response time if dependencies are not changing
disableJspRuntimeCompilation true - Alternatively, set this to false if JSP files are not pre-compiled and therefore need to be compiled on the first request. false

If the reloadEnabled parameter is set to true, a JSP file is reloaded at run time if the JSP file and its class file do not have the same timestamp. In addition, if trackDependencies is set to true then the JSP file is reloaded if the timestamp of any of its dependencies has changed since the JSP class file was last generated. If the reloadEnabled parameter is set to false, a JSP file is still compiled if necessary on the first request to it unless the parameter disableJspRuntimeCompilation is true. For example, when disableJspRuntimeCompilation is false and reloadEnabled is false, a JSP file is compiled on the first request if the class file is outdated. It would not compiled on subsequent requests even if the JSP source file is modified or the class file is deleted unless reloadEnabled is true

 

Reload interval

The reload interval is set through the reloadInterval JSP engine parameter: 

<jspAttributes xmi:id="JSPAttribute_1" name="reloadInterval" value="5"/>
If reloading is enabled, the reloadInterval parameter value determines the delay between checks to see if a JSP file is outdated. For example, if reloadInterval is 5, the JSP engine checks to see if a JSP file is outdated only when the last such check was done more than five seconds prior to the current request for the JSP file. Once the reloadInterval is exceeded, reload checking is performed and the reload interval timer is reset to 0 for that JSP file. The larger the reloadInterval, the less frequently the JSP engine checks for the need to reload a JSP file.

 

Dependency tracking

Dependency tracking is set through the trackDependencies JSP engine parameter: 

<jspAttributes xmi:id="JSPAttribute_1" name="trackDependencies" value="true"/>
If reloading is enabled, the trackDependencies parameter value determines whether the JSP engine tracks modifications to the requested JSP file dependencies as well as to the JSP file itself. The three types of dependencies tracked by the JSP engine are:

Dependency tracking information is always included in the generated class file even if trackDependencies is false. The information is not used by the JSP engine or batch compiler unless the trackDependencies parameter is true. This means that you can enable dependency tracking without having to recompile JSP files.

For example, the toplevel.jsp file statically includes the footer.jspf file. When the toplevel.jsp file is compiled, the path to the footer.jspf file and its timestamp are stored in the toplevel.jsp's class file. As a result, the footer.jspf file is modified and the toplevel.jsp file is requested. Now that the reload interval for the toplevel.jsp file has been exceeded, the JSP engine compares the timestamp stored in the class file with the footer.jspf file timestamp on disk. Because the timestamps are different, the toplevel.jsp file is compiled, picking up the modification to the footer.jspf file. In order for dependency tracking to work, the trackDependencies value must be set to true at the time a JSP file is requested at run time or is processed by the batch compiler.

 

Disabling compilation

Disablement of run time compilation of JavaServer Pages is set via the disableJspRuntimeCompilation JSP engine parameter: 

<jspAttributes xmi:id="JSPAttribute_1" name="disableJspRuntimeCompilation" value="true"/>
If the disableJspRuntimeCompilation parameter is set to true, the JSP engine at run time does not translate and compile JSP files; the JSP engine loads only precompiled class files. JSP source files do not need to be present in order for the class files to be loaded. With this option set to true, an application can be installed without JSP source, but must have precompiled class files. There is a Web container custom property of the same name that can be used to determine the behavior of all web modules installed in a server. If both the Web container custom property and the JSP engine option are set, the JSP engine option takes precedence. Setting the disableJspRuntimeCompilation parameter to true automatically sets reloadEnabled to false.

 

Reload processing sequence

The processing sequence pertaining to JSP file reloading when trackDependencies is false is shown in Figure 1. Figure 1. Reload processing sequence when trackDependencies is false.

When trackDependencies is true, the JSP engine does additional file system processing to determine if any of a JSP file's dependencies have changed since the JSP file was last translated and compiled. Figure 2 shows the additional processes that are performed on the 'No' path of flow chart labeled "is JSP class file outdated?". You can see that the path taken when disableJspRuntimeCompilation is true is the most efficient path. Figure 2. Additional reload processing performed when trackDependencies is true.



 

Related tasks


Configure JSP engine parameters

 

Related Reference


JSP engine configuration parameters
Custom property settings
Web container custom properties

 

Reference topic