SpringMVC 九大组件之 HandlerAdapter 深入分析

2年前 (2022) 程序员胖胖胖虎阿
114 0 0

@[toc] SpringMVC 九大组件,前面和大家分析了 HandlerMapping,今天我们来看 HandlerAdapter。因为前面已经做了很多铺垫了,所以今天的内容不会太难。

SpringMVC 中通过 HandlerAdapter 来让 Handler 得到执行,为什么拿到 Handler 之后不直接执行呢?那是因为 SpringMVC 中我们定义 Handler 的方式多种多样(虽然日常开发中我们都是使用注解来定义,但是实际上还有其他方式),不同的 Handler 当然对应不同的执行方式,所以这中间就需要一个适配器 HandlerAdapter。

1.HandlerAdapter 体系

我们先来看看 HandlerAdapter 大致的继承关系:

SpringMVC 九大组件之 HandlerAdapter 深入分析

可以看到,这里涉及到的子类并不多,而且看名字基本上就知道这个是干啥的。

这里除了 RequestMappingHandlerAdapter 比较复杂之外,其他几个都是比较容易的,容易是因为这几个调用的方法都是固定的,复杂则是因为调用的方法不固定。我们先来看看这几个容易的。

2.HandlerAdapter

HttpRequestHandlerAdapter、SimpleServletHandlerAdapter、HandlerFunctionAdapter、SimpleControllerHandlerAdapter,这四个里边,HandlerFunctionAdapter 用来处理 HandlerFunction 类型的接口,函数式 Web 框架现在呼声很高,但是实际应用的并不多,因此这里我们暂且忽略它,来看另外三个。

HttpRequestHandlerAdapter

HttpRequestHandlerAdapter 主要用来处理实现了 HttpRequestHandler 接口的 handler,例如像下面这种:

public class HelloController01 implements HttpRequestHandler {
    @Override
    public void handleRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.getWriter().write("hello");
    }
}

HttpRequestHandlerAdapter#handle 方法也很简单,直接调用 handleRequest:

public class HttpRequestHandlerAdapter implements HandlerAdapter {
	@Override
	public boolean supports(Object handler) {
		return (handler instanceof HttpRequestHandler);
	}
	@Override
	@Nullable
	public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {
		((HttpRequestHandler) handler).handleRequest(request, response);
		return null;
	}
	@Override
	public long getLastModified(HttpServletRequest request, Object handler) {
		if (handler instanceof LastModified) {
			return ((LastModified) handler).getLastModified(request);
		}
		return -1L;
	}
}

可以看到,supports 方法判断 handler 的类型是否是 HttpRequestHandler,handle 方法则直接调用 handleRequest。

SimpleControllerHandlerAdapter

SimpleControllerHandlerAdapter 主要用来处理实现了 Controller 接口的 handler,像下面这样:

public class HelloController02 implements Controller {
    @Override
    public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
        return new ModelAndView("hello");
    }
}

SimpleControllerHandlerAdapter 的定义也很简单:

public class SimpleControllerHandlerAdapter implements HandlerAdapter {

	@Override
	public boolean supports(Object handler) {
		return (handler instanceof Controller);
	}

	@Override
	@Nullable
	public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {

		return ((Controller) handler).handleRequest(request, response);
	}

	@Override
	public long getLastModified(HttpServletRequest request, Object handler) {
		if (handler instanceof LastModified) {
			return ((LastModified) handler).getLastModified(request);
		}
		return -1L;
	}

}

这个应该不用再解释了吧。

SimpleServletHandlerAdapter

这个用来处理实现了 Servlet 接口的 handler,在实际开发中我们很少用到这种,我就不多说,我们直接来看它的源码:

public class SimpleServletHandlerAdapter implements HandlerAdapter {

	@Override
	public boolean supports(Object handler) {
		return (handler instanceof Servlet);
	}

	@Override
	@Nullable
	public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {

		((Servlet) handler).service(request, response);
		return null;
	}

	@Override
	public long getLastModified(HttpServletRequest request, Object handler) {
		return -1;
	}

}

可以看到,也很简单!handle 方法中直接调用 servlet 的 service 方法。

可以看到,这三种 HandlerAdapter 简单的原因主要是因为要调用的方法比较简单,直接调用就可以了。而 RequestMappingHandlerAdapter 复杂是因为调用的方法名不固定,所以复杂。

3.RequestMappingHandlerAdapter

RequestMappingHandlerAdapter 继承自 AbstractHandlerMethodAdapter,我们先来看看 AbstractHandlerMethodAdapter。

3.1 AbstractHandlerMethodAdapter

public abstract class AbstractHandlerMethodAdapter extends WebContentGenerator implements HandlerAdapter, Ordered {
	private int order = Ordered.LOWEST_PRECEDENCE;
	public AbstractHandlerMethodAdapter() {
		super(false);
	}
	public void setOrder(int order) {
		this.order = order;
	}
	@Override
	public int getOrder() {
		return this.order;
	}
	@Override
	public final boolean supports(Object handler) {
		return (handler instanceof HandlerMethod && supportsInternal((HandlerMethod) handler));
	}
	protected abstract boolean supportsInternal(HandlerMethod handlerMethod);
	@Override
	@Nullable
	public final ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {

		return handleInternal(request, response, (HandlerMethod) handler);
	}
	@Nullable
	protected abstract ModelAndView handleInternal(HttpServletRequest request,
			HttpServletResponse response, HandlerMethod handlerMethod) throws Exception;
	@Override
	public final long getLastModified(HttpServletRequest request, Object handler) {
		return getLastModifiedInternal(request, (HandlerMethod) handler);
	}
	protected abstract long getLastModifiedInternal(HttpServletRequest request, HandlerMethod handlerMethod);
}

AbstractHandlerMethodAdapter 还是比较简单的,前面我们说的三个方法还是没变,只不过三个方法里边分别调用了 supportsInternal、handleInternal 以及 getLastModifiedInternal,而这些 xxxInternal 都将在子类 RequestMappingHandlerAdapter 中被实现。另外 AbstractHandlerMethodAdapter 实现了 Ordered 接口,意味着在配置的时候还可以设置优先级。

这就是 AbstractHandlerMethodAdapter,比较简单。

3.2 RequestMappingHandlerAdapter

RequestMappingHandlerAdapter 承担了大部分的执行工作,通过前面的介绍,我们已经大致知道 RequestMappingHandlerAdapter 中主要实现了三个方法:supportsInternal、handleInternal 以及 getLastModifiedInternal。其中 supportsInternal 总是返回 true,意味着在 RequestMappingHandlerAdapter 中不做任何比较,getLastModifiedInternal 则直接返回 -1,所以对它来说,最重要的其实是 handleInternal 方法。

整体上来说,RequestMappingHandlerAdapter 要解决三方面的问题:

  1. 处理请求参数。
  2. 调用处理器执行请求。
  3. 处理请求响应。

三个问题第一个最复杂!大家想想我们平时定义接口时,接口参数是不固定的,有几个参数、参数类型是什么都不确定,有的时候我们还利用 @ControllerAdvice 注解标记了一些全局参数,等等这些都要考虑进来,所以这一步是最复杂的,剩下的两步就比较容易了。对于参数的处理,SpringMVC 中提供了很多参数解析器,在接下来的源码分析中,我们将一步一步见识到这些参数解析器。

3.2.1 初始化过程

那么接下来我们就先来看 RequestMappingHandlerAdapter 的初始化过程,由于它实现了 InitializingBean 接口,因此 afterPropertiesSet 方法会被自动调用,在 afterPropertiesSet 方法中,完成了各种参数解析器的初始化:

@Override
public void afterPropertiesSet() {
	// Do this first, it may add ResponseBody advice beans
	initControllerAdviceCache();
	if (this.argumentResolvers == null) {
		List<handlermethodargumentresolver> resolvers = getDefaultArgumentResolvers();
		this.argumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
	}
	if (this.initBinderArgumentResolvers == null) {
		List<handlermethodargumentresolver> resolvers = getDefaultInitBinderArgumentResolvers();
		this.initBinderArgumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
	}
	if (this.returnValueHandlers == null) {
		List<handlermethodreturnvaluehandler> handlers = getDefaultReturnValueHandlers();
		this.returnValueHandlers = new HandlerMethodReturnValueHandlerComposite().addHandlers(handlers);
	}
}
private void initControllerAdviceCache() {
	if (getApplicationContext() == null) {
		return;
	}
	List<controlleradvicebean> adviceBeans = ControllerAdviceBean.findAnnotatedBeans(getApplicationContext());
	List<object> requestResponseBodyAdviceBeans = new ArrayList&lt;&gt;();
	for (ControllerAdviceBean adviceBean : adviceBeans) {
		Class<!--?--> beanType = adviceBean.getBeanType();
		if (beanType == null) {
			throw new IllegalStateException("Unresolvable type for ControllerAdviceBean: " + adviceBean);
		}
		Set<method> attrMethods = MethodIntrospector.selectMethods(beanType, MODEL_ATTRIBUTE_METHODS);
		if (!attrMethods.isEmpty()) {
			this.modelAttributeAdviceCache.put(adviceBean, attrMethods);
		}
		Set<method> binderMethods = MethodIntrospector.selectMethods(beanType, INIT_BINDER_METHODS);
		if (!binderMethods.isEmpty()) {
			this.initBinderAdviceCache.put(adviceBean, binderMethods);
		}
		if (RequestBodyAdvice.class.isAssignableFrom(beanType) || ResponseBodyAdvice.class.isAssignableFrom(beanType)) {
			requestResponseBodyAdviceBeans.add(adviceBean);
		}
	}
	if (!requestResponseBodyAdviceBeans.isEmpty()) {
		this.requestResponseBodyAdvice.addAll(0, requestResponseBodyAdviceBeans);
	}
}

这里首先调用 initControllerAdviceCache 方法对包含了 @ControllerAdvice 注解的类进行处理(如果有小伙伴对 @ControllerAdvice 注解的使用还不熟悉,可以在公众号【江南一点雨】后台回复 666 或者 ssm,有松哥的入门教程,里边都有关于 @ControllerAdvice 的讲解),具体的处理思路如下:

  1. 首先查找到所有标记了 @ControllerAdvice 注解的 Bean,将查找结果保存到 adviceBeans 变量中。
  2. 接下来遍历 adviceBeans,找到对象中包含 @ModelAttribute 注解的方法,将查找的结果保存到 modelAttributeAdviceCache 变量中。
  3. 找到对象中包含 @InitBinder 注解的方法,将查找的结果保存到 initBinderAdviceCache 变量中。
  4. 查找实现了 RequestBodyAdvice 或者 ResponseBodyAdvice 接口的类,并最终将查找结果添加到 requestResponseBodyAdvice 中。实现了 RequestBodyAdvice 或者 ResponseBodyAdvice 接口的类一般需要用 @ControllerAdvice 注解标记,关于这两个接口的详细用法,读者可以参考松哥之前的文章,传送门如何优雅的实现 Spring Boot 接口参数加密解密?。另外这里还需要注意,找到的 adviceBean 并没有直接放到全局变量中,而是先放在局部变量中,然后才添加到全局的 requestResponseBodyAdvice 中,这种方式可以确保 adviceBean 始终处于集合的最前面。

这就是 initControllerAdviceCache 方法的处理逻辑,主要是解决了一些全局参数的处理问题。

我们再回到 afterPropertiesSet 方法中,接下来就是对 argumentResolvers、initBinderArgumentResolvers 以及 returnValueHandlers 的初始化了。

前两个参数相关的解析器,都是通过 getDefaultXXX 方法获取的,并且把获取的结果添加到 HandlerMethodArgumentResolverComposite 中,这种 xxxComposite,大家一看就知道是一个责任链模式,这个里边管理了诸多的参数解析器,但是它自己不干活,需要工作的时候,它就负责遍历它所管理的参数解析器,让那些参数解析器去处理参数问题。我们先来看看它的 getDefaultXXX 方法:

private List<handlermethodargumentresolver> getDefaultArgumentResolvers() {
	List<handlermethodargumentresolver> resolvers = new ArrayList&lt;&gt;(30);
	// Annotation-based argument resolution
	resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), false));
	resolvers.add(new RequestParamMapMethodArgumentResolver());
	resolvers.add(new PathVariableMethodArgumentResolver());
	resolvers.add(new PathVariableMapMethodArgumentResolver());
	resolvers.add(new MatrixVariableMethodArgumentResolver());
	resolvers.add(new MatrixVariableMapMethodArgumentResolver());
	resolvers.add(new ServletModelAttributeMethodProcessor(false));
	resolvers.add(new RequestResponseBodyMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice));
	resolvers.add(new RequestPartMethodArgumentResolver(getMessageConverters(), this.requestResponseBodyAdvice));
	resolvers.add(new RequestHeaderMethodArgumentResolver(getBeanFactory()));
	resolvers.add(new RequestHeaderMapMethodArgumentResolver());
	resolvers.add(new ServletCookieValueMethodArgumentResolver(getBeanFactory()));
	resolvers.add(new ExpressionValueMethodArgumentResolver(getBeanFactory()));
	resolvers.add(new SessionAttributeMethodArgumentResolver());
	resolvers.add(new RequestAttributeMethodArgumentResolver());
	// Type-based argument resolution
	resolvers.add(new ServletRequestMethodArgumentResolver());
	resolvers.add(new ServletResponseMethodArgumentResolver());
	resolvers.add(new HttpEntityMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice));
	resolvers.add(new RedirectAttributesMethodArgumentResolver());
	resolvers.add(new ModelMethodProcessor());
	resolvers.add(new MapMethodProcessor());
	resolvers.add(new ErrorsMethodArgumentResolver());
	resolvers.add(new SessionStatusMethodArgumentResolver());
	resolvers.add(new UriComponentsBuilderMethodArgumentResolver());
	if (KotlinDetector.isKotlinPresent()) {
		resolvers.add(new ContinuationHandlerMethodArgumentResolver());
	}
	// Custom arguments
	if (getCustomArgumentResolvers() != null) {
		resolvers.addAll(getCustomArgumentResolvers());
	}
	// Catch-all
	resolvers.add(new PrincipalMethodArgumentResolver());
	resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), true));
	resolvers.add(new ServletModelAttributeMethodProcessor(true));
	return resolvers;
}
private List<handlermethodargumentresolver> getDefaultInitBinderArgumentResolvers() {
	List<handlermethodargumentresolver> resolvers = new ArrayList&lt;&gt;(20);
	// Annotation-based argument resolution
	resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), false));
	resolvers.add(new RequestParamMapMethodArgumentResolver());
	resolvers.add(new PathVariableMethodArgumentResolver());
	resolvers.add(new PathVariableMapMethodArgumentResolver());
	resolvers.add(new MatrixVariableMethodArgumentResolver());
	resolvers.add(new MatrixVariableMapMethodArgumentResolver());
	resolvers.add(new ExpressionValueMethodArgumentResolver(getBeanFactory()));
	resolvers.add(new SessionAttributeMethodArgumentResolver());
	resolvers.add(new RequestAttributeMethodArgumentResolver());
	// Type-based argument resolution
	resolvers.add(new ServletRequestMethodArgumentResolver());
	resolvers.add(new ServletResponseMethodArgumentResolver());
	// Custom arguments
	if (getCustomArgumentResolvers() != null) {
		resolvers.addAll(getCustomArgumentResolvers());
	}
	// Catch-all
	resolvers.add(new PrincipalMethodArgumentResolver());
	resolvers.add(new RequestParamMethodArgumentResolver(getBeanFactory(), true));
	return resolvers;
}

这两个方法虽然挺长的,但是内容都比较简单。在 getDefaultArgumentResolvers 方法中,解析器被分为四类:

  1. 通过注解标记的参数对应的解析器。
  2. 通过类型解析的解析器。
  3. 自定义的解析器。
  4. 兜底的解析器(大部分前面搞不定的参数后面的都能搞定,简单数据类型就是在这里处理的)。

getDefaultInitBinderArgumentResolvers 方法也是类似的,我就不再赘述。

所谓的解析器实际上就是把参数从对应的介质中提取出来,然后交给方法对应的变量。如果项目有需要,也可以自定义参数解析器,自定义的参数解析器设置到 RequestMappingHandlerAdapter#customArgumentResolvers 属性上,在调用的时候,前两种参数解析器都匹配不上的时候,自定义的参数解析器才会有用,而且这个顺序是固定的无法改变的。

关于参数解析器本身,如果大家不是特别熟悉的话,可以看看松哥之前的文章:

  • SpringBoot 中如何自定义参数解析器?
  • 深入分析 SpringMVC 参数解析器

3.2.2 请求执行过程

根据前面的介绍,请求执行的入口方法实际上就是 handleInternal,所以这里我们就从 handleInternal 方法开始分析:

@Override
protected ModelAndView handleInternal(HttpServletRequest request,
		HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {
	ModelAndView mav;
	checkRequest(request);
	// Execute invokeHandlerMethod in synchronized block if required.
	if (this.synchronizeOnSession) {
		HttpSession session = request.getSession(false);
		if (session != null) {
			Object mutex = WebUtils.getSessionMutex(session);
			synchronized (mutex) {
				mav = invokeHandlerMethod(request, response, handlerMethod);
			}
		}
		else {
			// No HttpSession available -&gt; no mutex necessary
			mav = invokeHandlerMethod(request, response, handlerMethod);
		}
	}
	else {
		// No synchronization on session demanded at all...
		mav = invokeHandlerMethod(request, response, handlerMethod);
	}
	if (!response.containsHeader(HEADER_CACHE_CONTROL)) {
		if (getSessionAttributesHandler(handlerMethod).hasSessionAttributes()) {
			applyCacheSeconds(response, this.cacheSecondsForSessionAttributeHandlers);
		}
		else {
			prepareResponse(response);
		}
	}
	return mav;
}

不过这个 handleInternal 方法看起来平平无奇,没啥特别之处。仔细看起来,它里边就做了三件事:

  1. checkRequest 方法检查请求。
  2. invokeHandlerMethod 方法执行处理器方法,这个是核心。
  3. 处理缓存问题。

那么接下来我们就对这三个问题分别进行分析。

checkRequest
protected final void checkRequest(HttpServletRequest request) throws ServletException {
	// Check whether we should support the request method.
	String method = request.getMethod();
	if (this.supportedMethods != null &amp;&amp; !this.supportedMethods.contains(method)) {
		throw new HttpRequestMethodNotSupportedException(method, this.supportedMethods);
	}
	// Check whether a session is required.
	if (this.requireSession &amp;&amp; request.getSession(false) == null) {
		throw new HttpSessionRequiredException("Pre-existing session required but none found");
	}
}

检查就检查了两个东西:

  1. 是否支持请求方法

当 supportedMethods 不为空的时候,去检查是否支持请求方法。默认情况下,supportedMethods 为 null,所以默认情况下是不检查请求方法的。如果需要检查,可以在注册 RequestMappingHandlerAdapter 的时候进行配置,如果在构造方法中设置 restrictDefaultSupportedMethods 变量为 true,那么默认情况下只支持 GET、POST、以及 HEAD 三种请求,不过这个参数改起来比较麻烦,默认在父类 AbstractHandlerMethodAdapter 类中写死了。

  1. 是否需要 session

如果 requireSession 为 true,就检查一下 session 是否存在,默认情况下,requireSession 为 false,所以这里也是不检查的。

invokeHandlerMethod

接下来就是 invokeHandlerMethod 方法的调用了:

@Nullable
protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
		HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {
	ServletWebRequest webRequest = new ServletWebRequest(request, response);
	try {
		WebDataBinderFactory binderFactory = getDataBinderFactory(handlerMethod);
		ModelFactory modelFactory = getModelFactory(handlerMethod, binderFactory);
		ServletInvocableHandlerMethod invocableMethod = createInvocableHandlerMethod(handlerMethod);
		if (this.argumentResolvers != null) {
			invocableMethod.setHandlerMethodArgumentResolvers(this.argumentResolvers);
		}
		if (this.returnValueHandlers != null) {
			invocableMethod.setHandlerMethodReturnValueHandlers(this.returnValueHandlers);
		}
		invocableMethod.setDataBinderFactory(binderFactory);
		invocableMethod.setParameterNameDiscoverer(this.parameterNameDiscoverer);
		ModelAndViewContainer mavContainer = new ModelAndViewContainer();
		mavContainer.addAllAttributes(RequestContextUtils.getInputFlashMap(request));
		modelFactory.initModel(webRequest, mavContainer, invocableMethod);
		mavContainer.setIgnoreDefaultModelOnRedirect(this.ignoreDefaultModelOnRedirect);
		AsyncWebRequest asyncWebRequest = WebAsyncUtils.createAsyncWebRequest(request, response);
		asyncWebRequest.setTimeout(this.asyncRequestTimeout);
		WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
		asyncManager.setTaskExecutor(this.taskExecutor);
		asyncManager.setAsyncWebRequest(asyncWebRequest);
		asyncManager.registerCallableInterceptors(this.callableInterceptors);
		asyncManager.registerDeferredResultInterceptors(this.deferredResultInterceptors);
		if (asyncManager.hasConcurrentResult()) {
			Object result = asyncManager.getConcurrentResult();
			mavContainer = (ModelAndViewContainer) asyncManager.getConcurrentResultContext()[0];
			asyncManager.clearConcurrentResult();
			LogFormatUtils.traceDebug(logger, traceOn -&gt; {
				String formatted = LogFormatUtils.formatValue(result, !traceOn);
				return "Resume with async result [" + formatted + "]";
			});
			invocableMethod = invocableMethod.wrapConcurrentResult(result);
		}
		invocableMethod.invokeAndHandle(webRequest, mavContainer);
		if (asyncManager.isConcurrentHandlingStarted()) {
			return null;
		}
		return getModelAndView(mavContainer, modelFactory, webRequest);
	}
	finally {
		webRequest.requestCompleted();
	}
}

这个方法里涉及到的组件比较多,不过大部分组件在前面的文章中松哥都已经和大家介绍过了,因此这里理解起来应该并不难。

  1. 首先获取一个 WebDataBinderFactory 对象,该对象将用来构建 WebDataBinder。
  2. 接下来获取一个 ModelFactory 对象,该对象用来初始化/更新 Model 对象(见:猜一猜,Model 中的数据放在 session 中还是 request 中?)。
  3. 接下来创建 ServletInvocableHandlerMethod 对象,一会方法的调用,将由它完成(见:Spring Boot 定义接口的方法是否可以声明为 private?)。
  4. 接下来给 invocableMethod 把需要的参数都安排上。
  5. 构造一个 ModelAndViewContainer 对象,将来用来存储 Model 和 View。
  6. 把 FlashMap 中的数据先添加进 ModelAndViewContainer 容器中(关于 FlashMap,参见:SpringMVC 中的参数还能这么传递?涨姿势了!)。
  7. 接下来初始化 Model,处理 @SessionAttributes 注解和 WebDataBinder 定义的全局数据,同时配置是否在重定向时忽略 defaultModel(具体初始化过程见:猜一猜,Model 中的数据放在 session 中还是 request 中?)。
  8. 接下来处理异步请求情况,判断是否有异步请求结果。
  9. 调用 invokeAndHandle 方法去真正执行接口方法,具体过程参见Spring Boot 定义接口的方法是否可以声明为 private?一文。
  10. 如果是异步请求,则直接返回即可。
  11. 接下来调用 getModelAndView 方法去构造 ModelAndView 并返回,在该方法中,首先会去更新 Model,更新的时候会去处理 SessionAttribute 同时配置 BindingResult;然后会根据 ModelAndViewContainer 去创建一个 ModelAndView 对象;最后,如果 ModelAndViewContainer 中的 Model 是 RedirectAttributes 类型,则将其设置到 FlashMap 中。
  12. 最后设置请求完成。
处理缓存

缓存的处理主要是针对响应头的 Cache-Control 字段。

这块比较简单,松哥就不废话了。

4.小结

今天这篇文章主要和小伙伴们聊了 SpringMVC 中的 HandlerAdapter,HandlerAdapter 中涉及到了很多其他的组件,这些组件松哥在之前的文章中已经向大家介绍过了,因此本文其实也可以看成是对前面文章所学习组件的一个梳理。当然这里涉及到的技术细节还是非常多,松哥以后抽空录视频和大家细聊。

好啦,本文我们就先说这么多~</handlermethodargumentresolver></handlermethodargumentresolver></handlermethodargumentresolver></handlermethodargumentresolver></method></method></object></controlleradvicebean></handlermethodreturnvaluehandler></handlermethodargumentresolver></handlermethodargumentresolver>

版权声明:程序员胖胖胖虎阿 发表于 2022年9月7日 上午3:32。
转载请注明:SpringMVC 九大组件之 HandlerAdapter 深入分析 | 胖虎的工具箱-编程导航

相关文章

暂无评论

暂无评论...