On the Application Server, the XML schema of web.xml is changed according to the Servlet 2.5 specifications.

The description about the omission of web.xml is added in the Servlet 2.5 specifications.

On the Application Server, when the Web application only contains JSP and static contents, you can omit web.xml. The Web application version in which web.xml is omitted is considered as 2.5. Also, when web.xml is omitted, you can omit the WEB-INF directory.

This point describes the precautions when web.xml is omitted. For the omission of web.xml, see 11.4.5 Operations related to Web applications in which web.xml is omitted in the uCosminexus Application Server Common Container Functionality Guide.

(a) Omitting web.xml when servlets and filters are included in the Web application

The servlets and filters require the mapping to be defined in web.xml, so if web.xml is omitted, the servlets and filters do not operate.

(b) Omitting web.xml when listener is included in the Web application

The following listeners need to be defined in web.xml, so if web.xml is omitted, the listeners do not operate:

• javax.servlet.ServletContextListener
• javax.servlet.ServletContextAttributeListener
• javax.servlet.ServletRequestListener
• javax.servlet.ServletRequestAttributeListener
• javax.servlet.http.HttpSessionListener
• javax.servlet.http.HttpSessionAttributeListener

However, the following listeners are not defined in web.xml, so even if web.xml is omitted, the listeners operate:

• javax.servlet.http.HttpSessionBindingListener
• javax.servlet.http.HttpSessionActivationListener

Also, if the listener is defined in the tag library, even if web.xml is omitted, the listener is executed.

(c) Setting the Web application properties in the execution environment

If web.xml is omitted, you cannot set properties with the server management commands and property files.

(d) Settings for mapping

Even if web.xml is omitted, the settings for mapping of files with extensions jsp and jspx, the default welcome file, session timeout, and default mime-mapping are enabled. Regardless of the settings for enabling or disabling the default servlet mapping, you cannot use the default servlet mapping.

(e) Using filters

In Web applications where web.xml is omitted, you cannot use filters. Therefore, functionality that require the built-in filter, such as the HTTP response compression functionality and the memory session failover functionality cannot be used.

In the web.xml schema defined in the Servlet 2.5 specifications, the value that can be specified in the <load-on-startup> element was changed.

On the Application Server, the value that can be specified in the <load-on-startup> element is controlled by the servlets corresponding to the version information of the Servlet specifications described in web.xml. The following table lists the values that can be specified in the <load-on-startup> element for each servlet version.

Table 6-16 Values that can be specified in the <load-on-startup> element

Servlet version	Specifiable values
Servlet 2.5	Integer or null character string. If a null character string is specified, the servlet is not loaded as in the case when the <load-on-startup> element is not specified.
Servlet 2.4	Integer. Specified value same as 07-60.

Note that if you specify a value that cannot be specified, the importing of the J2EE application will fail.

In the web.xml schema defined in the Servlet 2.5 specifications, the contents that can be specified in the <http-method> element in the <security-constraint><web-resource-collection> element were changed. The following table lists the specifiable contents:

Table 6-17 Contents specifiable in the <http-method> element in the <security-constraint><web-resource-collection> element

Servlet version	Specifiable contents
Servlet 2.5	One-byte alphanumeric characters (0-9, A-Z, a-z) and special characters (! # $ % & ' * + - . ^ _ ` | ~) can be specified one or more times.
Servlet 2.4	Either GET, POST, PUT, DELETE, HEAD, OPTIONS, or TRACE.

Specify the HTTP method of the request in the <http-method> element in the <security-constraint><web-resource-collection> element.

The HTTP method of the request supported in the application server is same as the contents supported in the servlet corresponding to the version information of the Servlet specifications described in web.xml. However, the HTTP method of the request supported in the Web application compliant with the Servlet 2.5 specifications differs depending on the Web server used. The HTTP method of the request supported in the Application Server is as follows, for each Web server:

Table 6-18 HTTP method of the request supported in the Application Server

Servlet version	Web server used	Specifiable contents
Servlet 2.5	Cosminexus HTTP Server and Microsoft IIS	Some of the methods that can be used in HTTP1.1#.
	In-process HTTP server	All the methods that can be used in HTTP1.1.
Servlet 2.4	Cosminexus HTTP Server, Microsoft IIS, In-process HTTP server	Either GET, POST, PUT, DELETE, HEAD, OPTIONS, or TRACE.

#

For details on the methods that can be specified, see Appendix A.2 Error status codes returned by the Redirector.

If you specify a value that cannot be specified, an attempt to import the J2EE application will fail.

Application Server supports the annotations defined in the Servlet 2.5 specifications. For using annotations, see 12. Using Annotations in the uCosminexus Application Server Common Container Functionality Guide.

The Servlet 2.5 specifications contain a description to continue the session in both the following cases when the session is created in the servlets and JSPs called in the cross context:

• Invoking cross context by a direct request for the associated context
• Invoking cross context by dispatch (invocation of the forward method and include method of the javax.servlet.RequestDispatcher interface)

However, in the Application Server, you cannot continue an HTTP session used when the Web application is invoked.

The Servlet 2.5 specifications contain a description about the specification of one-byte asterisk (*) in the <servlet-name> element in the <filter-mapping> element of web.xml.

By specifying an asterisk (*) in the <servlet-name> element in the <filter-mapping> element of web.xml, you can invoke the filter for the requests to all the servlets.

An example of definition in web.xml is as follows:

<filter-mapping> <filter-name>All Filter</filter-name> <servlet-name>*</servlet-name> </filter-mapping>

In this example, the filter with filter name All Filter is invoked for the requests to all the servlets.

Note

In the Web applications compliant with the Servlet 2.4 specifications, the one-byte asterisk (*) specified in the filter mapping did not have a special meaning. However, in the Web applications compliant with the Servlet 2.5 specifications, asterisk (*) implies all the servlets. Note that there is no method to specify only the servlets with servlet name asterisk (*).

In the application server, if one-byte asterisk (*) is specified in the <filter-mapping><servlet-name> element of web.xml, a filter is invoked for all the requests to the Web applications containing the relevant web.xml.

The Servlet 2.5 specifications clearly specify that the invocation of the setCharacterEncoding method is disabled after invoking the getReader method of the javax.servlet.ServletRequest interface.

The Application Server follows the Servlet 2.5 specifications regardless of the servlet version. The invocation of the setCharacterEncoding method is disabled after the getReader method is invoked and the following contents are not changed:

• Character encoding used in the BufferedReader object acquired with the getReader method
• Return value of the getCharacterEncoding method

With versions prior to the version 07-60, the return value of the getCharacterEncoding method was changed by invoking the setCharacterEncoding method after the getReader method was invoked, but in 08-00, the return value is not changed regardless of the servlet version.

The Servlet 2.5 specifications clearly specify that when the getRequestURL method of the javax.servlet.http.HttpServletRequest interface is invoked in the forwarding destination, the path used for acquiring the javax.servlet.RequestDispatcher object is applied as the URL that becomes the return value and not the URL path specified in the client.

On Application Server, the URL that becomes the return value is determined as per the servlet corresponding to the version information of the Servlet specifications described in web.xml.

In the Servlet 2.5 specifications, the path specified in the argument of the getRequestDispatcher method of the javax.servlet.ServletRequest interface invoked for acquiring the javax.servlet.RequestDispatcher object becomes the return value. In the Servlet 2.4 specifications, the path of the request URL becomes the return value.

In the Servlet 2.5 specifications, the specification is deleted related to the java.lang.IllegalStateException exception that is thrown when the getId method of the disabled javax.servlet.http.HttpSession object is invoked.

On Application Server, the value that is returned when the getId method of the disabled javax.servlet.http.HttpSession object was invoked, is controlled by the servlet as per the version information of the Servlet specifications coded in web.xml.

In the case of the Servlet 2.5 specifications, the return value is session ID and in the case of the Servlet 2.4 specifications, the return value is null same as in the case of version 07-60.

When the cross context is invoked between Web applications with different servlet versions, depending on the servlet version in the invocation source and invocation destination, there are methods in which the operations of the invocation destination are different. The following table describes the operations for each method at the invocation destination of the cross context when the cross context is invoked between the Web applications with different servlet versions:

Table 6-19 Operations at the invocation destination of the cross context between the Web applications with different servlet versions (getRequestURL method of the javax.servlet.http.HttpServletRequest interface)

Servlet version of the Web application		Operations at the invocation destination of the cross context	Reference
Invocation source	Invocation destination
Servlet 2.5	Version prior to Servlet 2.4	The operations follow the Servlet 2.5 specifications.	6.2.4 (9)
Versions prior to Servlet 2.4	Servlet 2.5	The operations follow the Servlet 2.4 specifications.

Table 6-20 Operations at the invocation destination of the cross context between the Web applications with different servlet versions (getId method of the disabled javax.servlet.http.HttpSession object)

Servlet version of the Web application		Operations at the invocation destination of the cross context	Reference
Invocation source	Invocation destination
Servlet 2.5	Version prior to Servlet 2.4	The operations follow the Servlet 2.5 specifications and return the session ID.	6.2.4 (10)
Versions prior to Servlet 2.4	Servlet 2.5	The operations follow the Servlet 2.4 specifications and return null.

According to the Servlet 2.5 specifications, the settings of the response header in the include destination servlet are enabled only for getSession. However, in Application Server, the settings of the response header in getSession are enabled even when Servlet 2.4 is used.