Analysis and Solutions for 'No Mapping Found for HTTP Request with URI' in Spring MVC DispatcherServlet

Nov 20, 2025 · Programming · 30 views · 7.8

Keywords: Spring MVC | DispatcherServlet | URL Mapping | ControllerClassNameHandlerMapping | @Controller Annotation

Abstract: This paper provides an in-depth analysis of the common 'No mapping found for HTTP request with URI' error in Spring MVC framework, focusing on the working mechanism of ControllerClassNameHandlerMapping and its impact on URL mapping. Through detailed code examples and configuration analysis, it explains the relationship between controller class names and request mappings, and offers multiple effective solutions. The article also discusses best practices for Spring MVC configuration, including component scanning, annotation-driven configuration, and default servlet handler usage, helping developers fundamentally understand and resolve such mapping issues.

Problem Background and Error Analysis

During Spring MVC application development, developers often encounter the "No mapping found for HTTP request with URI" error reported by DispatcherServlet. This error typically indicates that the Spring framework cannot map incoming HTTP requests to corresponding controller methods. The root cause often lies in improper HandlerMapping configuration or incomplete controller definitions.

ControllerClassNameHandlerMapping Working Mechanism

ControllerClassNameHandlerMapping is a URL mapping strategy in Spring MVC based on controller class names. This mapper automatically generates URL mappings for controller classes, following the naming convention of converting the controller class name to lowercase and removing the "Controller" suffix. For example, for a controller class named MyController, ControllerClassNameHandlerMapping automatically generates URL mappings prefixed with /my.

Consider the following controller definition:

public class myController {
    @RequestMapping("/hello")
    public ModelAndView helloWorld() {
        String message = "Hello World, Spring 3.0!";
        return new ModelAndView("hello", "message", message);
    }
}

When using ControllerClassNameHandlerMapping, the actual URL mapping path will be /my/hello, rather than directly mapping to /hello. This automatic prefix addition mechanism is the main reason for confusion among many developers.

Detailed Solution Analysis

The most direct solution to the above problem is to add the @Controller annotation to the controller class:

@Controller
public class myController {
    @RequestMapping("/hello")
    public ModelAndView helloWorld() {
        String message = "Hello World, Spring 3.0!";
        return new ModelAndView("hello", "message", message);
    }
}

After adding the @Controller annotation, the access URL should be adjusted to /<webappname>/my/hello.html. The my prefix here is automatically generated by ControllerClassNameHandlerMapping based on the controller class name myController.

Configuration Optimization Recommendations

In addition to adding necessary annotations, the completeness of Spring MVC configuration is also crucial. It is recommended to add the following configuration in spring-servlet.xml:

<context:component-scan base-package="com.mycompany.elso" />
<mvc:annotation-driven/>
<mvc:default-servlet-handler/>
<bean class="org.springframework.web.servlet.mvc.support.ControllerClassNameHandlerMapping"/>

The <mvc:annotation-driven/> configuration enables Spring MVC's annotation-driven functionality, including support for annotations such as @Controller and @RequestMapping. <mvc:default-servlet-handler/> is used to handle static resource requests, preventing DispatcherServlet from intercepting all requests.

Component Scanning and Package Configuration

Ensuring that component scanning configuration correctly points to packages containing controllers is crucial. If the package path is configured incorrectly, Spring will not be able to discover and register controller beans, leading to mapping failures. Additionally, avoid defining component scanning in multiple configuration files, as this may cause bean definition conflicts.

URL Pattern Matching Analysis

In web.xml, the DispatcherServlet's URL pattern is configured with multiple patterns:

<url-pattern>*.html</url-pattern>
<url-pattern>/</url-pattern>
<url-pattern>*.htm</url-pattern>

This configuration means that DispatcherServlet will handle all requests ending with .html, .htm, and all root path requests. When accessing hello.html, DispatcherServlet will attempt to map it to the corresponding controller method.

View Resolver Configuration

The UrlBasedViewResolver configuration ensures correct resolution of JSP views:

<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/jsp/" />
    <property name="suffix" value=".jsp" />
</bean>

When the controller returns the logical view name "hello", the view resolver will resolve it to the physical path /WEB-INF/jsp/hello.jsp.

Summary and Best Practices

Although Spring MVC's URL mapping mechanism is powerful, it requires developers to deeply understand its working principles. The automatic prefix feature of ControllerClassNameHandlerMapping, while useful in certain scenarios, may also lead to unexpected behavior. It is recommended in project development to:

  1. Always use the @Controller annotation on controller classes
  2. Clearly understand the working mechanisms of various HandlerMappings
  3. Properly configure component scanning paths to avoid package path errors
  4. Use <mvc:annotation-driven/> to enable complete annotation support
  5. Properly handle static resources through <mvc:default-servlet-handler/>

By following these best practices, developers can avoid common URL mapping issues and build more stable and maintainable Spring MVC applications.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.