The web.xml deployment descriptor is the central configuration file for Java web applications. It defines how the web container should deploy, configure, and manage the application's components including servlets, filters, listeners, and security settings. The deployment descriptor follows a strict XML schema that enforces element ordering and cardinality rules.

<web-app>
    <description> <!-- 0 or more -->
    <display-name> <!-- 0 or more -->
    <icon> <!-- 0 or more -->
        <small-icon> <!-- 0 or 1 -->
        <large-icon> <!-- 0 or 1 -->
    </icon>
    <welcome-file-list>
        <welcome-file> <!-- 0 or more -->
    </welcome-file-list>
    <context-param> <!-- 0 or more -->
        <param-name> <!-- always 1 -->
        <param-value> <!-- always 1 -->
    </context-param>
    <distributable> <!-- optional -->
    
    <!-- Servlet, Filter, Security, and JSP configurations follow -->
</web-app>

Important: The element ordering within <web-app> is strictly enforced by the servlet specification. Elements must appear in the exact sequence defined by the schema, or the web container will reject the deployment descriptor during application startup.

The metadata elements provide descriptive information about the web application and configure basic application-wide settings that affect how the container handles requests and manages the application lifecycle.

1. Description and Display Elements
   These elements provide human-readable information about the web application for administrative tools, development environments, and deployment management systems.
   

   <description>My Sample Web Application</description>
   <display-name>Sample Web Application</display-name>
   <icon>
       <small-icon>/images/mywebapp-icon-16.png</small-icon>
       <large-icon>/images/mywebapp-icon-32.png</large-icon>
   </icon>

   The <description> element provides detailed information about the application's purpose and functionality. The <display-name> offers a short, user-friendly name that administrative tools can display. Icon elements specify application icons for use in management interfaces.
   
2. Welcome Files Configuration
   The <welcome-file-list> element defines the default files that the web container should serve when a user requests a directory without specifying a particular file. The container searches for these files in the order they are listed.
   

   <welcome-file-list>
       <welcome-file>index.html</welcome-file>
       <welcome-file>index.jsp</welcome-file>
       <welcome-file>default.html</welcome-file>
   </welcome-file-list>

   When a user accesses a directory URL (like http://mtitek.com/mywebapp/), the container will look for index.html first, then index.jsp, then default.html. The first file found will be served to the client. If no welcome files are found, the container's default behavior applies (typically showing a directory listing or a 404 error).
   
3. Context Parameters
   Context parameters define application-wide initialization parameters that are available to all servlets, filters, and listeners within the web application. These parameters are accessible through the ServletContext interface and are commonly used for configuration settings that need to be shared across the entire application.
   

   <context-param>
       <param-name>mywebapp.param1</param-name>
       <param-value>mywebapp-param1-value</param-value>
   </context-param>
   <context-param>
       <param-name>mywebapp.param1</param-name>
       <param-value>mywebapp-param1-value</param-value>
   </context-param>

   Context parameters can be retrieved programmatically using ServletContext.getInitParameter("parameter-name"). This approach allows for externalized configuration without hardcoding values in the application source code.
   

Servlet configuration involves two main aspects: declaring servlets with their implementation details and mapping them to specific URL patterns. This two-step process provides flexibility in how servlets are exposed to client requests.

1. Servlet Declaration
   The <servlet> element declares a servlet within the web application, specifying its implementation class, initialization parameters, and loading behavior. Each servlet declaration creates a logical name that can be referenced by servlet mappings.
   

   <servlet>
       <description>mywebapp requests</description>
       <display-name>mywebapp Servlet</display-name>
       <servlet-name>MyWebAppServlet</servlet-name>
       <servlet-class>com.mtitek.mywebapp.servlets.MyWebAppServlet</servlet-class>
       <init-param>
           <param-name>mywebapp.servlet.param1</param-name>
           <param-value>mywebapp-servlet-param1-value</param-value>
       </init-param>
       <load-on-startup>1</load-on-startup>
   </servlet>

   The <init-param> elements provide servlet-specific initialization parameters accessible through the ServletConfig interface. The <load-on-startup> element controls when the servlet is instantiated: negative values or absence means load on first request, zero or positive values indicate loading at startup with the numeric value determining loading order.
   
2. Servlet URL Mapping
   The <servlet-mapping> element associates a declared servlet with one or more URL patterns, determining which requests are routed to the servlet. This separation between declaration and mapping allows for flexible URL design and servlet reuse.
   

   <servlet-mapping>
       <servlet-name>MyWebAppServlet</servlet-name>
       <url-pattern>/login</url-pattern>
   </servlet-mapping>
   <servlet-mapping>
       <servlet-name>MyWebAppServlet</servlet-name>
       <url-pattern>/logout</url-pattern>
   </servlet-mapping>

   URL patterns can be exact matches (/login), path-based (/* or /admin/*), or extension-based (*.jsp). The servlet specification defines precedence rules for pattern matching when multiple patterns could apply to the same request.
   

Filters provide a mechanism for preprocessing requests and postprocessing responses in a web application. Like servlets, filters require both declaration and mapping configuration to function properly.

1. Filter Declaration
   The <filter> element declares a filter class and its initialization parameters. Filters intercept requests before they reach servlets and can modify requests, responses, or both.
   

   <filter>
       <description>mywebapp requests filter</description>
       <display-name>mywebapp Filter</display-name>
       <filter-name>MyWebAppFilter</filter-name>
       <filter-class>com.mtitek.mywebapp.filters.MyWebAppServletFilter</filter-class>
       <init-param>
           <param-name>mywebapp.servlet.filter.param1</param-name>
           <param-value>mywebapp-servlet-filter-param1-value</param-value>
       </init-param>
   </filter>

   Filter initialization parameters work similarly to servlet parameters, providing configuration data accessible through the FilterConfig interface during filter initialization.
   
2. Filter Mapping and Dispatchers
   The <filter-mapping> element determines which requests are processed by a filter. Filters can be mapped to URL patterns or specific servlets, and can be configured to apply to different types of request dispatching.
   

   <filter-mapping>
       <filter-name>MyWebAppFilter</filter-name>
       <url-pattern>/*</url-pattern>
       <dispatcher>REQUEST</dispatcher>
       <dispatcher>FORWARD</dispatcher>
   </filter-mapping>

   The <dispatcher> element specifies when the filter should be applied: REQUEST (normal client requests), FORWARD (internal forwards), INCLUDE (includes), or ERROR (error page processing). Multiple dispatcher elements can be specified to apply the filter to different request types.
   

These elements configure session management, event handling, and MIME type handling for the web application.

1. Session Timeout Settings
   The <session-config> element configures HTTP session behavior, primarily the session timeout period.
   

   <session-config>
       <session-timeout>30</session-timeout>
   </session-config>

   The timeout value is specified in minutes. A value of 0 or negative means sessions never timeout automatically. This setting affects all sessions created within the web application.
   
2. Event Listeners
   The <listener> element registers event listeners that respond to lifecycle events in the web application, such as application startup/shutdown, session creation/destruction, or attribute changes.
   

   <listener>
       <listener-class>com.mtitek.mywebapp.listeners.ApplicationStartupListener</listener-class>
   </listener>

   Listeners must implement appropriate listener interfaces such as ServletContextListener, HttpSessionListener, or ServletRequestListener depending on the events they need to handle.
   
3. MIME Type Mappings
   The <mime-mapping> element defines custom MIME type associations for file extensions, overriding or supplementing the container's default MIME type mappings.
   

   <mime-mapping>
       <extension>pdf</extension>
       <mime-type>application/pdf</mime-type>
   </mime-mapping>
   <mime-mapping>
       <extension>json</extension>
       <mime-type>application/json</mime-type>
   </mime-mapping>

   These mappings affect the Content-Type header sent by the server when serving static files and can influence how browsers handle downloaded content.
   

The <error-page> element configures custom error pages for specific HTTP error codes or Java exception types, providing a better user experience when errors occur.

<error-page>
    <error-code>404</error-code>
    <location>/error/404.html</location>
</error-page>
<error-page>
    <exception-type>java.lang.NullPointerException</exception-type>
    <location>/error/exception.jsp</location>
</error-page>

Error pages can be mapped to specific HTTP status codes or Java exception types. When an error occurs, the container forwards the request to the specified location, where error information is available through request attributes.

Security configuration encompasses role definitions, access constraints, and authentication mechanisms that protect web application resources.

1. Security Roles and Constraints
   Security roles define logical groups of users, while security constraints specify which resources require authentication and authorization.
   

   <security-role>
       <role-name>admin</role-name>
   </security-role>
   <security-role>
       <role-name>user</role-name>
   </security-role>
   
   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Admin Area</web-resource-name>
           <url-pattern>/admin/*</url-pattern>
           <http-method>GET</http-method>
           <http-method>POST</http-method>
       </web-resource-collection>
       <auth-constraint>
           <role-name>admin</role-name>
       </auth-constraint>
       <user-data-constraint>
           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
       </user-data-constraint>
   </security-constraint>

   The <web-resource-collection> defines the resources to protect, <auth-constraint> specifies which roles can access them, and <user-data-constraint> defines transport requirements (NONE, INTEGRAL, or CONFIDENTIAL for HTTPS).
   
2. Authentication Configuration
   The <login-config> element configures the authentication mechanism and associated parameters for the web application.
   

   <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>Customer Portal</realm-name>
       <form-login-config>
           <form-login-page>/login.html</form-login-page>
           <form-error-page>/login-error.html</form-error-page>
       </form-login-config>
   </login-config>

   Authentication methods include BASIC (HTTP Basic), FORM (custom login form), DIGEST (HTTP Digest), and CLIENT-CERT (certificate-based). Form-based authentication requires specifying login and error page locations.