Identify the Exact Spring MVC Controller Behind Any Request with Cloud‑Native Insight

Background

In a live Spring Cloud environment, identifying which controller handles a particular request often requires manual code inspection, which is error‑prone and time‑consuming. Alibaba Cloud Microservice Insight (MSE) provides a zero‑code way to observe the exact controller that processes a request at runtime.

Demo Applications

The demo consists of four Spring Cloud services that call each other in sequence:

log-demo-spring-cloud-zuul

log-demo-spring-cloud-a

log-demo-spring-cloud-b

log-demo-spring-cloud-c

Source code: https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/mse-simple-demo

Spring MVC Dispatch Flow

When a request reaches a Spring Cloud application, the core processing is performed by org.springframework.web.servlet.DispatcherServlet#doDispatch. The method determines the handler by invoking DispatcherServlet#getHandler, which returns a HandlerExecutionChain that contains the concrete controller method.

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    HttpServletRequest processedRequest = request;
    HandlerExecutionChain mappedHandler = null;
    boolean multipartRequestParsed = false;
    WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
    try {
        ModelAndView mv = null;
        Exception dispatchException = null;
        try {
            processedRequest = checkMultipart(request);
            multipartRequestParsed = (processedRequest != request);
            // Determine handler for the current request.
            mappedHandler = getHandler(processedRequest);
            if (mappedHandler == null) {
                noHandlerFound(processedRequest, response);
                return;
            }
            // Determine handler adapter for the current request.
            HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
            // … further processing …
        }
    }
}

Observing getHandler with Microservice Insight

Create an MSE rule that sets org.springframework.web.servlet.DispatcherServlet#getHandler as the Target . Use the default instance selection (all instances) and do not add any traffic filter. Enable the rule and select the method’s return value as the output field. In the MSE console the mse.return attribute shows the concrete controller, e.g.:

java.lang.String com.alibabacloud.mse.demo.AApplication$AController.a

Exception Stack‑Trace Analysis

To diagnose a failing request, define a rule with the failing URL (for example /sql) as the Target, enable the exception filter , and select “call stack” as the output. After the rule is active, the console displays the full Java stack trace, allowing you to pinpoint the business methods involved. Example excerpt:

at com.mysql.cj.jdbc.ClientPreparedStatement.executeQuery(ClientPreparedStatement.java:989)
  at com.alibaba.druid.pool.DruidPooledPreparedStatement.executeQuery(DruidPooledPreparedStatement.java:213)
  at com.alibabacloud.mse.demo.service.DruidCon.doCommond(DruidCon.java:57)
  at com.alibabacloud.mse.demo.service.DruidService.query(DruidService.java:15)
  at com.alibabacloud.mse.demo.BApplication$AController.sql(BApplication.java:89)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Collecting Method Parameters

To inspect the runtime arguments of a specific business method (e.g., com.alibabacloud.mse.demo.service.DruidCon.doCommond), create another rule with that method as the Target, keep the exception filter enabled, and select “request parameters” as the output. The console then shows the actual parameter values without any code changes.

Benefits of Zero‑Code Observability

MSE enables dynamic, point‑in‑time data collection for any Java method. Developers can obtain return values, parameters, thread context, and full stack traces without adding logging statements or redeploying the service, dramatically reducing the effort required to troubleshoot hard‑to‑reproduce issues.

Beyond Observation

The same rule‑based model can be combined with governance actions such as rate limiting, fault isolation, or circuit breaking. By linking observation results to automatic mitigation, systems can maintain optimal behavior during traffic spikes or upstream instability.