This subsection describes the precautions for using web.xml with specifications added and changed in Servlet version 2.4 or later on Application Server. For details on the Servlet version 2.4 or later specifications, see the applicable Servlet specifications.
With Application Server, you cannot define the following web.xml elements with Servlet 2.4 or later specifications. If such elements are defined, an error occurs during deployment:
With Servlet 2.4 or later specifications, a postscript is added for the operations when a particular value is specified in the <security-constraint> tag of web.xml.
With Application Server, execute the following operations regardless of the Web application version:
With Servlet 2.4 or later specifications, a postscript is added for the operations when multiple <security-constraint> tags are defined in web.xml.
The operations when multiple <security-constraint> tags are defined on Application Server are described separately for Servlet 2.4 or later versions and Servlet 2.3:
With Servlet 2.4 or later specifications, a postscript is added for operations when the linefeed code is included in the URL pattern that is coded in web.xml.
With Application Server, regardless of the Web application version, the KDJE39304-W warning message is output. However, no error occurs and the application starts. The relevant mapping will also be ignored.
Note that the tags that perform such operations in web.xml are <servlet-mapping> tag, <filter-mapping> tag, <jsp-property-group> tag, and <web-resource-collection> tag and the <url-pattern> tag of the sub-classes included in each tag.
With the Web applications compliant with Servlet 2.4 or later specifications, even if you specify the error page to be displayed by web.xml, the status code of the response when the error occurs is sent to the client.
With the applications compliant with Servlet 2.2 specifications and Servlet 2.3 specifications, the status code 200 is sent to the client.
With the applications compliant with Servlet 2.4 or later specifications, when you display the error page specified in web.xml, the error page is not customized. Also, if you specify an error page customized for the same status code, an error occurs in the Web application and the customization is enabled only when an attempt to output the error page specified in web.xml fails.
For details on customizing the error page, see 2.20 Customizing the error pagein the manual uCosminexus Application Server Web Container Functionality Guide.
With the applications compliant with Servlet 2.4 or later specifications, if the status code after the error page specified in web.xml is displayed matches with the error status code entrusted with the creation of the error page, the error page created by the Web server is enabled. At this time, the contents of the error page specified in web.xml are destroyed after being transferred to the redirector.
By changing the response status code in the error page specified in web.xml to 200, you can enable the error page specified in web.xml.
For details on redirecting as per the status code, see 5.15.1 Error pages that can be customized in the manual uCosminexus Application Server Web Container Functionality Guide.
With the Web applications compliant with Servlet 2.4 or later specifications, when you define the <filter-mapping> tag of web.xml, by coding the <dispatcher> tag as a sub element, you can operate a filter when a request is forwarded, included, and transferred to the error page coded in web.xml.
With a JSP, you can use the errorPage attribute of the page directive to output an error page when an exception occurs in JSP. However, the transfer of requests executed at this time is a Forward. The definition required in the <dispatcher> tag when applying the filter is 'FORWARD' and not 'ERROR'.