Processing during execution of JSP pre-compilation

When the JSP pre-compilation is executed, validity check of web.xml and version check of the JSP compilation results are implemented.

(a) Validity check of web.xml

With the JSP pre-compilation functionality, whether the web.xml conforms to the DTD or XML schema is verified before execution of compilation processing. Moreover, the validity of settings for the elements referenced during JSP pre-compilation is also verified to the extent necessary for JSP pre-compilation. If the elements do not conform to the schema, an error occurs during the translation of JSP that generates a Java file from the JSP file.

The following table describes the elements of web.xml verified during execution of JSP pre-compile.

Table 2-11 Elements of web.xml verified during execution of JSP pre-compilation

Tag names				Tag description	Servlet version
Tag names				Tag description	2.2	2.3	2.4	2.5	3.0
<!DOCTYPE>				DOCTYPE declaration	Y	Y	N	N	N
<web-app>				Root tag	Y	Y	Y	Y	Y
	<servlet>			Definitions about the servlet	Y	Y	Y	Y	Y
		<jsp-file>		JSP file name	Y	Y	Y	Y	Y
	<taglib>			Definitions about the tag library	Y	Y	--	--	--
		<taglib-uri>		URI of tag library	Y	Y	--	--	--
		<taglib-location>		Location of tag library descriptor file (TLD)	Y	Y	--	--	--
	<jsp-config>			Definitions about the JSP	--	--	Y	Y	Y
		<taglib>		Definitions about the tag library	--	--	Y	Y	Y
			<taglib-uri>	URI of tag library	--	--	Y	Y	Y
			<taglib-location>	Location of tag library descriptor file (TLD)	--	--	Y	Y	Y
		<jsp-property-group>		Settings of JSP that matches with the specified URL pattern	--	--	Y	Y	Y
			<url-pattern>	URL pattern of JSP for which installation is applied	--	--	Y	Y	Y
			<el-ignored>	Settings indicating whether to ignore EL (Expression Language)	--	--	Y	Y	Y
			<scripting-invalid>	Settings indicating whether to disable the scripting element	--	--	Y	Y	Y
			<page-encoding>	Page encoding name	--	--	Y	Y	Y
			<include-prelude>	File included as the JSP header	--	--	Y	Y	Y
			<include-coda>	File included as the JSP footer	--	--	Y	Y	Y
			<is-xml>	Settings indicating whether coding is done in XML format	--	--	Y	Y	Y
			<deferred-syntax-allowed-as-literal>	Settings indicating whether the presence of #{ string in the part where EL is not used is to be considered as an error	--	--	--	Y	Y
			<trim-directive-whitespaces>	Settings indicating whether to output extra spaces from JSP	--	--	--	Y	Y

Legend:: Y: Verified; N: Not verified; --: Unsupported element

(b) Version check of JSP compilation results

When using the JSP pre-compilation functionality, check if the version of the Web application specified in web.xml for the J2EE server matches with the version of JSP during JSP compilation. The version check is implemented in the following cases:

If the implementation of JSP pre-compilation is not specified when application is started (when the application is started with the cjstartapp command, without specifying the -jspc option)
If JSP pre-compilation is executed in each Web application with the cjjspc command by specifying the files excluded from the compilation
If JSP pre-compilation is executed in each JSP file using the cjjspc command

The class files generated from JSP depend on the version of the Web application specified in web.xml. You cannot use the class files in a Web application whose version is different from the version of the Web application during execution of JSP pre-compilation. Consequently, if the version of a Web application is changed, you need to compile all the JSP files.

Note that in the following cases, since all JSP files included in a Web application are compiled, the JSP compilation result is not checked.

If the JSP pre-compilation is executed in each Web application without specifying the files to be excluded from compilation
If the JSP pre-compilation used when starting the application is executed

Reference note

When version check of JSP compilation results is implemented, a version information file containing the version information of the JSP files is generated in the JSP working directory of the Web application to be compiled. The version information file is generated at the following location:

Web-application-directory/WEB-INF/JSP-work-directory-name/WEB-INF/JSP-work-directory-name/jsp_compile_info

(c) TLD file check

You validate whether the TLD file complies with DTD or XML schema during the JSP pre-compilation. The following is the description for TLD file check related to each version of Web applications:

When the version of Web application is 2.4 or later
Validation is executed by default. Note that if the TLD file is not in accordance with the schema, an error will occur during the translation of the JSP file.
When the version of Web application is 2.3 or earlier
Specify in advance whether validation is to be performed. If you specify settings to validate the TLD file, the TLD file will be validated during the JSP pre-compilation.
For details on the validation of TLD files, see 2.5.8 Execution environment settings (J2EE server settings).

(2) Handling JSP files in application in which the JSP pre-compilation functionality is implemented

This subsection explains the operation of a J2EE application in which the JSP pre-compilation functionality is executed.

(a) Operations when a request is executed and a J2EE application is started

When JSP pre-compilation is being implemented, JSP compilation is not implemented during execution of a request. The class files of JSP created during pre-compilation are loaded and executed.

In such a case, an error occurs if the class files compiled from the JSP files do not exist. The following table describes the behavior of the J2EE server when JSP pre-compilation is implemented and the files do not exist:

Table 2-12 Behavior of the J2EE server when the files do not exist (when JSP pre-compilation is executed)

Non-existent files		Behavior of the J2EE server
JSP files	JSP files	JSP file is not referenced
JSP files	Class file	Error 404 is returned
Tag files	Tag files	Tag file is not referenced
Tag files	Class file	Error 500 is returned (java.lang.NoClassDefFoundError occurs)
Statically included file		Statically included file is not referenced
TLD file		TLD file is not referenced

The J2EE server operates as follows, when the pre-compilation is not implemented and the files do not exist:

Table 2-13 Behavior of the J2EE server when the files do not exist (when JSP pre-compilation is not executed)

Non-existent files		Behavior of the J2EE server
JSP files	JSP files	Error 404 is returned
JSP files	Class file	JSP files are compiled
Tag files	Tag files	Error 500 is returned (compilation error)
Tag files	Class file	Tag files are compiled
Statically included file		Error 500 is returned (compilation error)
TLD file		Error 500 is returned (compilation error)

(b) Operation when a J2EE application is started

If you pre-compile the JSP files of a Web application in which <load-on-startup> is specified in the JSP files with web.xml, JSP compilation is not implemented when a J2EE application is started. The class files generated during JSP pre-compilation are loaded and jspInit method is executed. In such a case, loading of JSP files fails, if the class files of JSP, or a class file on which JSP depends does not exist.

Note that if the settings for error notification in servlet and JSP are enabled, the operation fails when starting a Web application. For details on the settings for error notification in servlets and JSPs, see 9.16 Settings for error notification in servlets and JSPs in the uCosminexus Application Server Application Setup Guide.

(3) Notes on JSP pre-compilation functionality

The notes related to the JSP pre-compilation functionality are as follows:

Sending requests in which jsp_precompile is added
Even if you send a request in which the query string jsp_precompile or jsp_precompile=true was added to an application that executes the JSP pre-compilation, the JSP compilation is not executed.
Operation of the same Web application by multiple invocations of the command for JSP pre-compilation
You cannot execute JSP pre-compilation in the same Web application by multiple invocations of the cjjspc command. Also, you cannot execute compilation in the same Web application with the cjjspc command, during execution of JSP pre-compilation when an application is started.
Note that due to the command locking process, a lock file will be generated in the JSP work directory during the execution of JSP pre-compilation functionality. The lock file is generated in the following location:
Web-application-directory/WEB-INF/JSP-work-directory-name/WEB-INF/JSP-work-directory-name/ExecutingJspPrecompilation.lock
Migrating to applications that use the JSP compilation results
When the J2EE application is in the archive format, the compilation results generated by the JSP pre-compilation functionality during the startup of the application will be deleted when the application is stopped.
The following is the procedure for using the JSP compilation results that are generated by the JSP pre-compilation functionality during the startup of the application, even after the application stops. The description is given for each J2EE application format.
In the case of a J2EE application of archive format
1. Execute the JSP pre-compilation when starting the application.
2. Export the application.
3. Replace with applications containing the JSP compilation results by using the redeploy functionality.
In the case of a J2EE application of exploded archive format
1. Execute JSP pre-compilation when the cjjspc command or application starts.
Migrating to applications that do not use the JSP compilation results
When you do not use the JSP compilation results generated by JSP pre-compilation, you need to delete each JSP working directory.
The procedure to be followed when you do not use the JSP compilation results is explained below for each format of J2EE application:
In the case of a J2EE application of archive format
1. Export the J2EE application.
2. Deploy the EAR file.
3. Delete each JSP working directory under Web-application-root-directory/WEB-INF.
4. Create the EAR file.
5. Switch the J2EE applications using the redeploy functionality.
In the case of a J2EE application of exploded archive format
1. Stop the J2EE application.
2. Delete each JSP working directory under Web-application-root-directory/WEB-INF.
3. Start the J2EE application.
Modifying files on which the JSP file depends
When a tag file, static included file, or TLD file is updated, compile all JSP files that reference the updated files.
Updating the exploded archive format J2EE applications that use the JSP pre-compilation functionality
Note the followings when you update the J2EE applications in exploded archive formats that use the JSP pre-compilation functionality:
- To add the JSP file or tag file into the J2EE application
  Compile all the JSP files that reference the added JSP file or tag file. Use the JSP pre-compilation functionality to compile the JSP file.
- To apply the JSP compilation results updated in the development environment to the execution environment
  Copy the class files exist under the JSP work directory of the J2EE application in the development environment to the JSP work directory of the J2EE application in the execution environment. In this case, copy all the class files updated during the JSP pre-compilation in the development environment.

2.5.4 Processing during execution of JSP pre-compilation