![[Contents]](FIGURE/CONTENT.GIF)
uCosminexus Application Server, Web Container Functionality Guide
![[Glossary]](FIGURE/GLOSS.GIF)
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
![[Next]](FIGURE/AFTER.GIF)
This subsection describes the precautions for using the specifications that were added and changed in JSP 2.1 on the application server. For details on the JSP 2.1 specifications and JSP 2.0 specifications, see the respective specifications (JSP 2.1 specifications and JSP 2.0 specifications).
The EL of the JSP 2.1 specifications integrates the EL of the JSP 2.0 specifications and the EL of the JSF1.1 specifications.
The EL syntax and API functions are determined as the EL 2.1 specifications and variables such as the implicit object defined in the JSP 2.1 specifications and JSF1.2 specifications can be used through the API functions of EL.
The following are the addition of the functionality related to EL of JSP 2.1 specifications. The changes in the specifications are described later.
In addition to the EL in ${} format that is a JSP 2.0 specification, you can describe EL in #{} format that is an EL of JSF1.1 specification as the functionality of JSP 2.1 specification.
In the JSP 2.1 specifications, the following elements were added in the <attribute> element of the TLD file in order to show whether it is a tag attribute that expects the #{} format:
Also, the attributes corresponding to the TLD elements specified here were added to the attribute directive of the tag file.
In the JSP 2.1 specifications, if EL in #{} format is described in the following locations along with the addition of the #{} format in the EL2.1 specifications, a translation error occurs:
On the application server, if true is specified for the following elements or attribute values, the translation error will not occur even if EL of the #{} format exists in the template text or in the attribute value of the custom tag that does not have delayed evaluation. #{} is output as it is in a string.
The following table describes whether a translation error occurs for the #{} EL when the settings in web.xml are combined with the settings in page and tag directive:
Table 6-26 Presence or absence of translation errors when the settings in web.xml are combined with the settings in page and tag directive
| <deferred-syntax-allowed-as-literal> element of web.xml | deferredSyntaxAllowedAsLiteral attribute of the page and tag directive | ||
|---|---|---|---|
| true | false | Not specified | |
| true | Y | -- | Y |
| false | Y | -- | -- |
| Not specified | Y | -- | -- |
In the JSP 2.1 specifications, functionality was added to delete the unwanted white spaces included in the JSP template text. In the application server, this functionality is supported according to the JSP 2.1 specifications.
If you specify true in the following element or attribute values, the template text with only white spaces is deleted when JSP is output.
However, the white spaces in continuation with the template text that is not a white space are not deleted.
Table 6-27 Enabling or disabling of the functionality for deleting white spaces when the settings in web.xml are combined with the settings in page and tag directive
| <trim-directive-whitespaces> element of web.xml | trimDirectiveWhitespaces attribute of page and tag directive | ||
|---|---|---|---|
| true | false | Not specified | |
| true | Y | -- | Y |
| false | Y | -- | -- |
| Not specified | Y | -- | -- |
Note that if the trimDirectiveWhitespaces attribute is set in the page directive of the JSP document or the tag directive of the XML syntax, the attribute is processed as follows depending on the setup value.
The following figure shows an example wherein a template text with only white spaces exists between the JSP elements:
Figure 6-8 Example wherein template text with only white spaces exists
![[Figure]](FIGURE/ZU051000.GIF)
The taglib directive from the first to fourth line is not output, and therefore is ignored. The new line from the first new line, second new line, and one-byte space in the third line forms a template text with white spaces only.
The fourth new line in the JSP page is not deleted since this is the white space continuing after the template text that is not a white space. Therefore, if the functionality for deleting white spaces is enabled, the text is output from the fourth new line up to [EOF].
In the JSP 2.1 specifications, a functionality is added to set a unique identifier for each translation (file included in the JSP and include directive) in the tag handler. You can use this functionality by implementing the JspIdConsumer interface in the tag handler. The package name of the JspIdConsumer interface is javax.servlet.jsp.tagext.
During the JSP execution, the Web Container uses the setJspId method of the interface and sets the identifier for the tag handler that implements this interface. The identifier is determined during the JSP compilation, and therefore, the identifier might be changed in the processing of each request.
Use the string id<N> as the unique identifier. <N> indicates an integer value. <N> is allocated in the range of 0 to 2,147,483,647.
In the JSP 2.1 specifications, the following classes and methods are added.
| Package name | Class name |
|---|---|
| javax.servlet.jsp | JspApplicationContext |
| Package name | Class name |
|---|---|
| javax.servlet.jsp.tagext | TagAttributeInfo |
| Package name | Class name | Method name |
|---|---|---|
| javax.servlet.jsp | JspFactory | getJspApplicationContext |
| javax.servlet.jsp.tagext | TagAttributeInfo | getDescription |
| isDeferredValue | ||
| isDeferredMethod | ||
| getExpectedTypeName | ||
| getMethodSignature | ||
| TagLibraryInfo | getTagLibraryInfos |
The application server supports annotations defined in the JSP 2.1 specifications. For using annotations, see 12. Using Annotations in the uCosminexus Application Server Common Container Functionality Guide.
The elements that can be described in the tag file were added in the JSP 2.1 specifications, so clarification of the tag file version is necessary. Therefore, in the application server, the tag file version is determined according to the JSP 2.1 specifications.
However, the tag file version must match in each tag file. The operations do not function properly if TLD files of different versions are used to execute the same tag file.
Note that even if versions that form the version determining elements of TLD file and implicit.tld are different, if the versions determined by the actual usage method match in each file, the operations are performed without a problem.
For example, as described in the following table, even if the versions of the TLD file and implicit.tld are different, the operations are performed without a problem when the tag file is used by always using TLD or when directory is always specified and used from JSP:
Table 6-28 Example when the versions of the version determining elements are different
| Version determining elements | Versions |
|---|---|
| TLD file that references a tag file | 2.1 |
| implicit.tld of the directory that deploys the tag file | 2.0 |
In the JSP 2.1 specifications, if rtexprvalue is false in the tag attribute settings, you cannot specify the expression of scripting elements in the tag attributes even if deferredValue or deferredMethod is true.
In the application server, even if the rtexprvalue is false in the tag attribute settings, you can specify the expression of scripting elements in the tag attributes if deferredValue or deferredMethod is true. The following table describes the compliance between the tag attribute settings in the application server and the specifiable elements:
Table 6-29 Compliance between the tag attribute settings and the specifiable elements
| Tag attribute settings | Specifiable elements | ||||
|---|---|---|---|---|---|
| rtexprvalue | deferredValue or deferredMethod | Strings | Expression (<%= %>) | EL(${}) | EL(#{}) |
| false | false | Y | -- | -- | -- |
| true | false | Y | Y | Y | -- |
| false | true | Y | Y | -- | Y |
| true | true | Y | Y | Y | Y |
The operations when the same JSP page is specified in the errorPage attribute of the page directive as the transition destination when an error occurs in the JSP page are as follows:
Table 6-30 Operations when the same JSP page is specified in the errorPage attribute of the page directive as the transition destination when an error occurs in the JSP page
| Version of the Servlet specifications/ JSP specifications | Contents |
|---|---|
| Servlet 2.5/JSP 2.1 | As in the case of the JSP 2.1 specifications, a translation error occurs#. |
| Servlet 2.4/JSP 2.0 | JSP is accessed. If an exception occurs, action is not taken for the exception and if the exception occurs infinitely, a stack overflow error may occur. |
An example of specification of transition destination when an error occurs in the JSP page forming the translation error in the following file configuration is as follows:
![[Figure]](FIGURE/ZU051100.GIF)
If you specify the same JSP page (example.jsp) in the transition destination used when an error occurs in the JSP page example.jsp with one of the following methods, a translation error occurs.
The following JSP pages are assumed to exist:
If an error occurs in the JSP page A and an error also occurs in the JSP page B, an exception is thrown and the page moves to JSP page A. In the structure described here, if an exception occurs infinitely, the stack overflow error occurs.
The tag files have two types of extensions - .tag and .tagx. Do not deploy tag files with the same names and only different extensions such as example.tag and example.tagx.
In the JSP2.1 specifications, if tag files with the same names and only different extensions are deployed, the tag library is disabled.
In the application server, even if tag files with the same names and only different extensions are deployed, the tag library is not disabled. However, the tag file uses the files searched from the file system. In the case of tag files with the same names and only different extensions, note that the files searched previously are used and the file search order does not function properly.
In the application server, the API specifications are changed according to the API specification changes in the JSP 2.1 specifications. For details on the changes in the javax.servlet.jsp.JspException operations, see 6.2.13 (2) Invocation of initCause(Throwable) for objects generated in javax.servlet.ServletException and javax.servlet.jsp.JspException.
If non-typesafe methods compliant with versions prior to JSP 2.0 are used for API functions with generic names used in the Web application classes, you can use the classes as they are even in 08-00 and later versions without any changes in the method operations. Note that a warning message (unchecked warning) will occur in the javac command during compilation, but the warning message does not affect operations. By applying annotation@SuppressWarnings("unchecked") in the places where the warning message occurs, the warning message will not occur.
As per the JSP 2.1 specifications, settings are added for the addition of BOM in the setup method of the character encoding for the JSP page and standard syntax tag files in the application server.
The JSP pages are controlled as per the JSP specifications to which the Web application conforms. The tag files are controlled as per the JSP specifications corresponding to the tag file version. The following table describes the method of distinction between the character encoding for the JSP pages and tag files.
Table 6-31 Method of distinction between the character encoding for the JSP pages and tag files
| Version of JSP specifications | Contents |
|---|---|
| JSP 2.1 | The character encoding is set as per the JSP 2.1 specifications. However, UTF-32 BOM is not supported. |
| JSP 2.0 | The settings for character encoding cannot be specified in the addition of BOM. If necessary, you can specify the character encoding in the <page-encoding> element in the <jsp-property-group> element of web.xml or in the pageEncoding attribute in the page and tag directive. |
For details on the character encoding in JSP files and tag files, see 6.2.6 (13) Character encoding supported in JSP.
In the JSP pages and tag files of the Web applications compliant with the Servlet 2.5 or later specifications, you can use one of the following methods to specify whether or not to set the character encoding in the addition of BOM:
In the JSP pages and tag files of the Web applications compliant with the Servlet 2.5 or later specifications, if the character encoding is not set in the addition of BOM, the character encoding for JSP pages is set as per the Servlet 2.4 specifications.
The mapping of the TLD file and URI is controlled as per the JSP specifications to which the Web application conforms. The following table lists the method of mapping the TLD file with URI for each version of the JSP specifications.
Table 6-32 Method of mapping the TLD file and URI
| Version | Mapping methods |
|---|---|
| Servlet 2.5 (JSP 2.1) | JSTL and JSF URI are automatically mapped as per the JSP 2.1 specifications. The URI to be mapped are as follows:
|
| Servlet 2.4 (JSP 2.0) | The TLD file and URI are not mapped automatically. If JSTL and JSF are used, deploy the TLD file with the JSTL and JSF specifications as in the case of normal TLD files. |
In Web applications compliant with the Servlet 2.5 or later specifications, automatic mapping is processed at top priority, so you cannot overwrite the mapping of the TLD file and URI.
Therefore, in the application server, you can use one of the following methods to specify whether to map the TLD file and URI automatically:
If you want to use multiple versions of tag libraries for each Web application, disable automatic mapping using these methods. If you disable automatic mapping, you can mix libraries of multiple versions by deploying the libraries in respective Web applications.
In the JSP 2.1 specifications, "#{" is added to the string indicating the start of EL.
The JSP pages and JSP documents are controlled as per the JSP specifications to which the Web applications conform. The tag files are controlled as per the JSP specifications corresponding to the tag file version. Also, the control differs depending on whether the EL settings are enabled.
The following table describes the controlling of the escape sequence that expresses "#" as a string for each version of the servlet and JSP specifications.
Table 6-33 Controlling of the escape sequence expressing # as a string
| Versions of Servlet specifications/ JSP specifications | Specifications | |||
|---|---|---|---|---|
| When EL settings are enabled | When EL settings are disabled | |||
| \$ output | \# output | \$ output | \# output | |
| Servlet 2.5/JSP 2.1 | $ | # | $ | # |
| Servlet 2.4/JSP 2.0 | $ | \# | $ | \# |
In the Web applications compliant with Servlet 2.5 specifications, "\#" is output as # by the escape sequence regardless of the conditions as in the case of "\$". Therefore, if you want to output "\#", you must describe "\\#".
For details on the escape sequence specifications of "\$"in the JSP 2.0 specifications, see 6.2.8 (15) Escape sequence of EL (Expression Language).
The processing corresponding to the Enum type object defined in the Java SE 5 specifications was added from the EL of JSP 2.1 specifications.
The JSP pages and JSP documents are controlled as per the JSP specifications to which the Web applications conform. The tag files are controlled as per the JSP specifications corresponding to the tag file version.
The following table describes the processing for the Enum type in EL for each version of the servlet and JSP specifications in the application server.
Table 6-34 Processing for the Enum type in EL
| Versions of Servlet specifications/ JSP specifications | Contents |
|---|---|
| Servlet 2.5/JSP 2.1 | Processed as per the JSP 2.1 specifications. |
| Servlet 2.4/JSP 2.0 | In spite of Enum type, the processing is performed like other objects as per the JSP 2.0 specifications. |
However, if you use API functions of EL defined in the JSP 2.0 specifications, but deprecated in the JSP 2.1 specifications, the API functions are processed in the range of EL functionality in JSP 2.0 specifications, regardless of the Web application version.
The JSP pages and JSP documents are controlled as per the JSP specifications to which the Web applications conform. The tag files are controlled as per the JSP specifications corresponding to the tag file version.
The following table describes the processing of <, >, lt, and gt operators in EL in the application server for each version of the servlet and JSP specifications.
Table 6-35 Processing of <, >, lt, and gt operators in EL
| Versions of Servlet specifications/ JSP specifications | Contents |
|---|---|
| Servlet 2.5/JSP 2.1 | The <, >, lt, and gt operators are processed as per the JSP 2.1 specifications. |
| Servlet 2.4/JSP 2.0 | The <, >, lt, and gt operators are processed as per the JSP 2.0 specifications. |
However, if you use API functions of EL defined in the JSP 2.0 specifications, but deprecated in the JSP 2.1 specifications, the API functions are processed in the range of EL functionality in JSP 2.0 specifications, regardless of the Web application version.
This point describes the API functions of EL for JSP specifications in the application server.
Corresponds to the API functions added in the JSP 2.1 specifications. When you use the EL functionality added in the JSP 2.1 specifications, use the API function of the javax.el package.
When you use the API functions of EL defined in the JSP 2.0 specifications, EL is evaluated as per the EL specifications defined in the JSP 2.0 specifications.
All Rights Reserved. Copyright (C) 2013, Hitachi, Ltd.