Understanding Spring AOP Principles and Spring MVC Request Processing Flow
This article explains the source‑level principles of Spring AOP and walks through the step‑by‑step request processing flow of Spring MVC, providing code snippets and design insights for backend developers preparing for interviews.
Spring AOP and Spring MVC are common interview topics in Chinese backend development; this article walks through their source‑level principles and request‑processing flow.
Spring AOP principle : each bean is proxied by JDK dynamic proxy or CGLIB depending on interfaces; beans have a chain of method interceptors (outer Spring core interceptor and inner user‑defined AOP interceptors). When a proxied method is invoked, the outer interceptor builds the inner interceptor chain based on pointcut expressions, and finally the default interceptor invokes the target method. The design follows the Chain‑of‑Responsibility pattern.
Proxy creation steps:
Instantiate a proxy factory with interceptor array, target interfaces, and target object.
The factory appends a default interceptor for the final method call.
Calling getProxy() returns a JDK or CGLIB proxy according to interface count.
Proxy invocation steps:
The outer interceptor is triggered.
It creates the inner interceptor chain, matching each interceptor with the method’s pointcut.
When the chain reaches the default interceptor, the target method is executed.
Spring MVC process (simplified):
DispatcherServlet sets request attributes (WebApplicationContext, LocaleResolver, ThemeResolver).
It obtains a HandlerExecutionChain for the request URL.
It retrieves the appropriate HandlerAdapter.
Executes pre‑handle interceptors in order.
Invokes the handler (which may be a proxied controller) to obtain a ModelAndView.
Executes post‑handle interceptors in reverse order.
Resolves the view name to a View instance.
Renders the view.
Key code snippets:
// 1. set attribute
request.setAttribute(WEB_APPLICATION_CONTEXT_ATTRIBUTE, getWebApplicationContext());
// 2. get handler
HandlerExecutionChain mappedHandler = getHandler(request);
// 3. get adapter
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// 4. pre‑handle loop
for (int i = 0; i < mappedHandler.getInterceptors().length; i++) {
HandlerInterceptor interceptor = mappedHandler.getInterceptors()[i];
if (!interceptor.preHandle(request, response, mappedHandler.getHandler())) {
return;
}
}
// 5. invoke handler
ModelAndView mv = ha.handle(request, response, mappedHandler.getHandler());
// 6. post‑handle loop
for (int i = mappedHandler.getInterceptors().length - 1; i >= 0; i--) {
HandlerInterceptor interceptor = mappedHandler.getInterceptors()[i];
interceptor.postHandle(request, response, mappedHandler.getHandler());
}
// 7. resolve view
View view = this.viewResolver.resolveViewName(mv.getViewName(), locale);
// 8. render view
view.render(mv.getModel(), request, response);The article also provides informal UML and flow diagrams (images) and notes that Spring’s transaction management is implemented as an interceptor.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
