26、SpringBoot 源码分析 - DispatcherServlet的getHandler二

处理大致流程图

 

AbstractHandlerMethodMapping的lookupHandlerMethod

继续上次的getMappingsByUrl,我故意弄了个一对多的看看情况。
 
他会都加到matches中。
 
因为有两个所以这里需要排序,排序会根据注解RequestMapping中的属性来进行排序,比如参数个数,请求头个数等等,具体可以自己看下:
 
比如我这里比较方法个数:
 
排序后就这样:
 
所以又会bestMatch = matches.get(0);获取最好的方法:
 

如果排序完,发现第二个和第一个比较是相同的,那就不知道要选哪个,所以会报异常。

HandlerMethod的createWithResolvedBean

方法获取后,还要进行bean的创建,因为你此时获取的可能只是bean名字,因为前面创建HandlerMethod的时候只是放了beanName,没有进行实例化。
 
获取到实例后,重新创建一个HandlerMethod
 
基本只是把属性重新赋值了下。
 

AbstractHandlerMapping的getHandlerExecutionChain获取执行链

其实这里就是要放入拦截器了,先创建一个执行链,然后遍历所有拦截器,如果匹配的话就加入其中。

	protected HandlerExecutionChain getHandlerExecutionChain(Object handler, HttpServletRequest request) {
   
     
		HandlerExecutionChain chain = (handler instanceof HandlerExecutionChain ?
				(HandlerExecutionChain) handler : new HandlerExecutionChain(handler));//创建执行链

		String lookupPath = this.urlPathHelper.getLookupPathForRequest(request, LOOKUP_PATH);
		for (HandlerInterceptor interceptor : this.adaptedInterceptors) {
   
     
			if (interceptor instanceof MappedInterceptor) {
   
     
				MappedInterceptor mappedInterceptor = (MappedInterceptor) interceptor;
				if (mappedInterceptor.matches(lookupPath, this.pathMatcher)) {
   
     //进行uri匹配
					chain.addInterceptor(mappedInterceptor.getInterceptor());
				}
			}
			else {
   
     
				chain.addInterceptor(interceptor);
			}
		}
		return chain;
	}

HandlerExecutionChain执行链

可以看到他定义了一个拦截器数组和列表,好像有点重复了。
 
或许是为了兼容构造方法吧:
 

拦截器为什么是MappedInterceptor类型的

我们要看拦截器怎么生成的,其实是在RequestMappingHandlerMapping实例化的方法里。
 
addInterceptors就是添加自定义的,里面还有好几层,是用一个代理WebMvcConfigurer的集合,里面就是我们自己配置类,要实现WebMvcConfigurer接口,实现添加拦截器方法addInterceptors即可。然后再加上下面两个。
 
关键在this.interceptors = registry.getInterceptors();,进行了处理:
 
因为拦截器只是一个接口,还需要有包含和排除等路径信息,所以将他们封装成了MappedInterceptor
 
最后适配一下放入adaptedInterceptors中:
 

其他的一些逻辑就不讲了,执行链获取后直接就返回,表示找到了处理器了,至于说其他的处理器映射器后面会讲,先把大致的流程讲完,所以下一篇继续将后面的getHandlerAdapter获取处理器适配器。

好了,今天就到这里了,希望对学习理解有帮助,大神看见勿喷,仅为自己的学习理解,能力有限,请多包涵。