Analysis and Solutions for DispatcherServlet URL Mapping Issues in Spring MVC

Problem Background and Phenomenon Analysis

During Spring MVC application development, developers frequently encounter 404 errors caused by DispatcherServlet configuration issues. The specific manifestation occurs when controller methods forward to JSP pages through InternalResourceViewResolver, resulting in "No mapping found for HTTP request with URI [/WEB-INF/pages/apiForm.jsp]" errors.

From the provided debug logs, we can observe the complete request processing flow:

13:45:02,034 DEBUG [org.springframework.web.servlet.view.JstlView] - 
Forwarding to resource [/WEB-INF/pages/apiForm.jsp] in InternalResourceView 'apiForm'
13:45:02,035 DEBUG [org.springframework.web.servlet.DispatcherServlet] - 
DispatcherServlet with name 'testapp2' determining Last-Modified value for [/WEB-INF/pages/apiForm.jsp]
13:45:02,038 DEBUG [org.springframework.web.servlet.DispatcherServlet] - No handler found in getLastModified
13:45:02,038 DEBUG [org.springframework.web.servlet.DispatcherServlet] - 
DispatcherServlet with name 'testapp2' processing request for [/WEB-INF/pages/apiForm.jsp]
13:45:02,038 WARN  [org.springframework.web.servlet.PageNotFound] - 
No mapping found for HTTP request with URI [/WEB-INF/pages/apiForm.jsp] in DispatcherServlet with name 'testapp2'

Root Cause Investigation

The core issue lies in the URL mapping configuration of DispatcherServlet in web.xml. When using <url-pattern>/*</url-pattern> pattern, all URL requests are intercepted by DispatcherServlet, including internal forward requests to JSP pages.

The Spring MVC view resolution process follows this sequence: controller returns view name → ViewResolver resolves to specific view → view executes rendering. For JSP views, InternalResourceView uses RequestDispatcher.forward() method to forward requests to actual JSP files. However, due to DispatcherServlet's /* configuration, this forwarded JSP request re-enters DispatcherServlet's processing pipeline.

DispatcherServlet attempts to find corresponding controller mapping for the /WEB-INF/pages/apiForm.jsp URL, but no such mapping is configured, resulting in "No mapping found" warning and 404 status return.

Solution One: Modify URL Mapping Pattern

The most direct and effective solution is modifying DispatcherServlet's URL mapping pattern to avoid intercepting JSP requests. Change the generic /* pattern to specific extension patterns:

<servlet-mapping>
  <servlet-name>dispatcher</servlet-name>
  <url-pattern>*.do</url-pattern>
</servlet-mapping>

This configuration approach offers several advantages:

• Clearly distinguishes controller requests from static resource requests
• Avoids DispatcherServlet's repeated processing of JSP forward requests
• Maintains URL clarity and readability
• Compatible with existing Spring MVC best practices

After modification, controller request URLs need corresponding adjustments, for example:

@RequestMapping(value="/api/form.do", method=RequestMethod.GET)
public String showForm() {
    return "apiForm";
}

Solution Two: Configure Dedicated Mapping for JSP

Another solution involves configuring dedicated servlet mapping for JSP files, leveraging servlet container's mapping priority rules. The Servlet specification dictates that exact path matching takes precedence over wildcard matching.

In Tomcat environments, add the following configuration:

<servlet-mapping>
  <servlet-name>jsp</servlet-name>
  <url-pattern>/WEB-INF/pages/*</url-pattern>
</servlet-mapping>

For non-Tomcat containers or scenarios requiring explicit definition:

<servlet>
  <servlet-name>jsp</servlet-name>
  <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>jsp</servlet-name>
  <url-pattern>/WEB-INF/pages/*</url-pattern>
</servlet-mapping>

Configuration Verification and Best Practices

Regardless of the chosen solution, ensure ViewResolver configuration is correct:

<bean id="viewResolver"
    class="org.springframework.web.servlet.view.UrlBasedViewResolver">
    <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
    <property name="prefix" value="/WEB-INF/pages/"/>
    <property name="suffix" value=".jsp"/>
</bean>

In practical projects, the following best practices are recommended:

• Use specific URL patterns (such as *.do, *.action, or /app/*) to distinguish controller requests
• Configure dedicated servlets or use Spring's resource handlers for static resources (CSS, JS, images)
• Enable DEBUG level logging in development environments for easier troubleshooting
• Regularly review web.xml configurations to ensure no conflicting URL mappings

Technical Principle Deep Dive

From the Servlet container perspective, URL mapping matching follows these rules:

1. Exact path matching (e.g., /api/form)
2. Longest path prefix matching (e.g., /api/*)
3. Extension matching (e.g., *.do)
4. Default servlet matching (/)

When DispatcherServlet is configured with /*, it essentially acts as the default servlet, intercepting all requests not matched by other mappings. The internal forward requests to JSP files恰好 fall into this category.

Spring MVC's InternalResourceView, during rendering, essentially accomplishes its task through server-side forwarding. This forwarding process occurs within the Servlet container, but the forwarded URL still needs to go through servlet mapping matching. This explains why 404 errors occur even when JSP files physically exist.

Conclusion and Extended Considerations

This paper thoroughly analyzes JSP page 404 issues caused by DispatcherServlet URL mapping configurations in Spring MVC and provides two validated solutions. Although this problem appears simple, it involves knowledge across multiple layers including Servlet specifications, Spring MVC architecture, and Web container working principles.

In actual project development, understanding these underlying principles is crucial for building stable and maintainable web applications. Through reasonable URL mapping strategies, developers can not only avoid the issues described in this paper but also enhance application security and performance.

As modern web development evolves toward RESTful architectures and frontend-backend separation patterns, similar configuration issues may appear in different forms. However, mastering these fundamental principles will help developers quickly identify and solve problems when facing new challenges.