本文我们尝试总结分析SpringMVC体系中的视图解析器-ViewResolver。其根据name解析视图View，通常鼓励实现类考虑国际化策略实现。
前置流程
DispatcherServlet#doDispatch-- DispatcherServlet#processDispatchResult-- DispatcherServlet#render-- DispatcherServlet#resolveViewName-- --view.render(mv.getModelInternal(), request, response);
DispatcherServlet中根据视图名称获取view代码如下所示，遍历循环viewResolvers尝试获取一个不为null的view。
@Nullable protected View resolveViewName(String viewName, @Nullable Map<String, Object> model, Locale locale, HttpServletRequest request) throws Exception { if (this.viewResolvers != null) { for (ViewResolver viewResolver : this.viewResolvers) { View view = viewResolver.resolveViewName(viewName, locale); if (view != null) { return view; } } } return null; }
ViewResolver 获取具体的View，SpringMVC调用View的Render方法来渲染视图-将model数据与视图结合在一起写入到response中。
ViewResolver 接口只有一个抽象方法如下所示：
@Nullable View resolveViewName(String viewName, Locale locale) throws Exception;
locale表示鼓励你支持国际化策略。如果当前实现类不能解析视图，那么请返回null以使得视图解析器链可以流转下去。
【1】ViewResolver
首先我们看下其家族树图示：
ViewResolver实现主要分为四大类：
- ① ContentNegotiatingViewResolver
- ② AbstractCachingViewResolver
- ③ ViewResolverComposite
- ④ BeanNameViewResolver
子类视图解析器如下
ViewResolverComposite AbstractCachingViewResolver ResourceBundleViewResolver XmlViewResolver UrlBasedViewResolver TilesViewResolver ScriptTemplateViewResolver InternalResourceViewResolver XsltViewResolver AbstractTemplateViewResolver GroovyMarkupViewResolver FreeMarkerViewResolver ThymeleafViewResolver AjaxThymeleafViewResolver ContentNegotiatingViewResolver BeanNameViewResolver
下面我们按照类别来分析其子类。
【1】ViewResolverComposite
为什么先说这个呢？ViewResolverComposite本身不是一个视图解析器，其使用了组合模式内部维护了一个private final List viewResolvers = new ArrayList<>();，将具体resolveViewName动作委派了具体的ViewResolver实例(委派模式)。是不是和HandlerMethodArgumentResolverComposite、HandlerMethodReturnValueHandlerComposite类型？
如下图所示，其实现了ViewResolver, Ordered, InitializingBean,ApplicationContextAware, ServletContextAware接口。这意味着其在实例化过程中会进行诸多操作：
Ordered，表示其可以排序；
InitializingBean，实例化时调用其afterPropertiesSet方法；
ApplicationContextAware，实例化时会调用setApplicationContext方法；
ServletContextAware，实例化时会调用setServletContext方法。
我们从其源码也可以知晓，ViewResolverComposite在实例化过程中对内部维护的ViewResolver 做了增强工作。
@Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { for (ViewResolver viewResolver : this.viewResolvers) { if (viewResolver instanceof ApplicationContextAware) { ((ApplicationContextAware)viewResolver).setApplicationContext(applicationContext); } } } @Override public void setServletContext(ServletContext servletContext) { for (ViewResolver viewResolver : this.viewResolvers) { if (viewResolver instanceof ServletContextAware) { ((ServletContextAware)viewResolver).setServletContext(servletContext); } } } @Override public void afterPropertiesSet() throws Exception { for (ViewResolver viewResolver : this.viewResolvers) { if (viewResolver instanceof InitializingBean) { ((InitializingBean) viewResolver).afterPropertiesSet(); } } }
如下代码所示，其解析视图的方法很简单：遍历viewResolvers，然后使用具体的viewResolver 去解析，返回view或者null。
@Override @Nullable public View resolveViewName(String viewName, Locale locale) throws Exception { for (ViewResolver viewResolver : this.viewResolvers) { View view = viewResolver.resolveViewName(viewName, locale); if (view != null) { return view; } } return null; }
【2】BeanNameViewResolver
BeanNameViewResolver将视图名字解析为bean name，找到上下文中该bean实例返回。bean需要实现View接口。
① 解析视图
其解析视图的方法如下所示，尝试根据viewName从ApplicationContext 找到对应的bean。如果ApplicationContext 中没有该bean直接返回null；如果该bean不是View类型也返回null；最后返回bean的实例。
@Override @Nullable public View resolveViewName(String viewName, Locale locale) throws BeansException { ApplicationContext context = obtainApplicationContext(); if (!context.containsBean(viewName)) { // Allow for ViewResolver chaining... return null; } if (!context.isTypeMatch(viewName, View.class)) { if (logger.isDebugEnabled()) { logger.debug("Found bean named '" + viewName + "' but it does not implement View"); } // Since we're looking into the general ApplicationContext here, // let's accept this as a non-match and allow for chaining as well... return null; } return context.getBean(viewName, View.class); }
② 实践
① 配置解析器
如下所示，配置两个视图解析器，SpringMVC.xml配置：
<!-- 配置视图解析器: 如何把 handler 方法返回值解析为实际的物理视图 --> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/"></property> <property name="suffix" value=".jsp"></property> </bean> <!-- ****** 配置视图 BeanNameViewResolver 解析器: 使用视图的名字来解析视图 ************ --> <!-- 通过 order 属性来定义视图解析器的优先级, order 值越小优先级越高 --> <bean class="org.springframework.web.servlet.view.BeanNameViewResolver"> <property name="order" value="10"></property> </bean>
InternalResourceViewResolver的order属性默认为Integer的最大值。
② 自定义View实现类
实例代码如下：
@Component public class HelloView implements View{ /*自定义视图，需配置BeanNameViewResolver*/ public String getContentType() { return "text/html"; } //视图渲染，转发前不可避免的重要一步！ public void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception { /*打印响应信息到浏览器页面*/ response.getWriter().print("hello view, time: " + new Date()); } }
测试方法：
@RequestMapping("/testView") public String testView(){ System.out.println("testView"); return "helloView"; //返回bean名字 }
result as follows ：
同理，可以通过继承AbstractExcelView 并实现其buildExcelDocument方法，来渲染Excel。如下所示：
public class ExcelView extends AbstractExcelView { @Override protected void buildExcelDocument(Map<String, Object> model, HSSFWorkbook workbook, HttpServletRequest request, HttpServletResponse response) throws Exception { // TODO Auto-generated method stub } }
【3】ContentNegotiatingViewResolver
内容协商视图解析器。简单来说就是根据viewName和Media Type(依据请求的文件名称或者Accept头)找到候选的View再根据MediaType和View的ContentType确定最优View。
如下所示，ContentNegotiatingViewResolver维护了集合defaultViews和viewResolvers表示其并不会进行“解析View”的具体动作。解析任务将会被委派给具体的ViewResolver执行。defaultViews集合提供了入口，用户可以通过该属性注入自定义视图解析器。
@Nullable private List<View> defaultViews; @Nullable private List<ViewResolver> viewResolvers;
① 继承类分析
如下图所示，ContentNegotiatingViewResolver继承了WebApplicationObjectSupport并实现了ViewResolver, Ordered, InitializingBean接口。那么这里我们要有个清晰认知，这些类/接口意味着什么。
实现了Order接口意味着其拥有order属性，内部viewResolver可以按照顺序执行。
实现了InitializingBean接口
如下图所示，如果bean实现了InitializingBean接口，那么在初始化过程中一定会调用其afterPropertiesSet方法。
我们看下其afterPropertiesSet方法。如下所示根据cnmFactoryBean的build方法获取一个contentNegotiationManager 实例。
@Override public void afterPropertiesSet() { if (this.contentNegotiationManager == null) { this.contentNegotiationManager = this.cnmFactoryBean.build(); } if (this.viewResolvers == null || this.viewResolvers.isEmpty()) { logger.warn("No ViewResolvers configured"); } }
cnmFactoryBean是什么呢？其是一个工厂bean-ContentNegotiationManagerFactoryBean。主要是生产一个contentNegotiationManager并使用ContentNegotiationStrategy配置contentNegotiationManager。如下所示其实现了FactoryBean、ServletContextAware以及InitializingBean 接口。
public class ContentNegotiationManagerFactoryBean implements FactoryBean<ContentNegotiationManager>, ServletContextAware, InitializingBean { //... }
ServletContextAware接口提供了方法 void setServletContext(ServletContext servletContext);
InitializingBean接口提供了方法void afterPropertiesSet() throws Exception;在bean属性被设置，并调用了一系列诸如BeanFactoryAware、ApplicationContextAware等提供的方法后，再调用afterPropertiesSet方法。
FactoryBean接口提供了方法T getObject() throws Exception; && Class getObjectType(); &&default boolean isSingleton() {return true;},主要用来生产一个object。
继承自WebApplicationObjectSupport
WebApplicationObjectSupport继承自ApplicationObjectSupport并实现了ServletContextAware接口。
ServletContextAware接口提供了void setServletContext(ServletContext servletContext);方法用来设置ServletContext。该方法执行时机在在bean属性设置后、ApplicationContextAware's setApplicationContext方法后但是在init方法前如InitializingBean's afterPropertiesSet及其他自定义初始化方法前。
ApplicationObjectSupport实现了ApplicationContextAware接口。ApplicationContextAware接口提供了方法void setApplicationContext(ApplicationContext applicationContext) throws BeansException;用来设置ApplicationContext 。该方法执行时机在bean属性设置后、init方法调用前如InitializingBean#afterPropertiesSet()方法及其他自定义初始化方法。注意，其同样在ResourceLoaderAware#setResourceLoader、ApplicationEventPublisherAware#setApplicationEventPublisher以及MessageSourceAware后，如果实现这些Aware接口。
ApplicationObjectSupport提供了方法protected void initApplicationContext() throws BeansException{ }让子类实现，WebApplicationObjectSupport实现了该方法。如下所示其首先调用父类的initApplicationContext方法，然后获取servletContext 交给子类的initServletContext方法。
@Override protected void initApplicationContext(ApplicationContext context) { super.initApplicationContext(context); if (this.servletContext == null && context instanceof WebApplicationContext) { this.servletContext = ((WebApplicationContext) context).getServletContext(); if (this.servletContext != null) { initServletContext(this.servletContext); } } }
ContentNegotiatingViewResolver实现了initServletContext方法。
@Override protected void initServletContext(ServletContext servletContext) { Collection<ViewResolver> matchingBeans = BeanFactoryUtils.beansOfTypeIncludingAncestors(obtainApplicationContext(), ViewResolver.class).values(); if (this.viewResolvers == null) { this.viewResolvers = new ArrayList<>(matchingBeans.size()); for (ViewResolver viewResolver : matchingBeans) { if (this != viewResolver) { this.viewResolvers.add(viewResolver); } } } else { for (int i = 0; i < this.viewResolvers.size(); i++) { ViewResolver vr = this.viewResolvers.get(i); if (matchingBeans.contains(vr)) { continue; } String name = vr.getClass().getName() + i; //进行bean的初始化过程 obtainApplicationContext().getAutowireCapableBeanFactory().initializeBean(vr, name); } } // 根据order进行排序 AnnotationAwareOrderComparator.sort(this.viewResolvers); // 设置上下文 this.cnmFactoryBean.setServletContext(servletContext); }
方法如上所示，从ApplicationContext拿到ViewResolver放到集合Collection matchingBeans中。如果自身成员属性viewResolvers为null，那么把matchingBeans中的ViewResolver放到自身成员属性viewResolvers中(除了当前对象哦)。如果自身成员属性viewResolvers不为null，那么遍历调用除了自身之外的ViewResolver的initializeBean方法，也就是bean的初始化过程。
protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) { if (System.getSecurityManager() != null) { AccessController.doPrivileged((PrivilegedAction<Object>) () -> { invokeAwareMethods(beanName, bean); return null; }, getAccessControlContext()); } else { invokeAwareMethods(beanName, bean); } Object wrappedBean = bean; if (mbd == null || !mbd.isSynthetic()) { wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName); } try { invokeInitMethods(beanName, wrappedBean, mbd); } catch (Throwable ex) { throw new BeanCreationException( (mbd != null ? mbd.getResourceDescription() : null), beanName, "Invocation of init method failed", ex); } if (mbd == null || !mbd.isSynthetic()) { wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName); } return wrappedBean; }
这里主要核心步骤如下：
① invokeAwareMethods(beanName, bean);如BeanFactoryAware
② applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);Bean后置处理器的前置方法
③ invokeInitMethods(beanName, wrappedBean, mbd);反射调用bean的init方法以及自定义初始化方法。这里如果判断是InitializingBean类型，则会先调用其afterPropertiesSet方法。
④ applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);Bean后置处理器的后置方法
② 视图解析
@Override @Nullable public View resolveViewName(String viewName, Locale locale) throws Exception { // 获取请求属性对象，实现类诸如 ServletRequestAttributes RequestAttributes attrs = RequestContextHolder.getRequestAttributes(); Assert.state(attrs instanceof ServletRequestAttributes, "No current ServletRequestAttributes"); // 获取请求接受的，并且响应能够生产的MediaType List<MediaType> requestedMediaTypes = getMediaTypes(((ServletRequestAttributes) attrs).getRequest()); // 获取候选View，然后得到一个BestView if (requestedMediaTypes != null) { List<View> candidateViews = getCandidateViews(viewName, locale, requestedMediaTypes); View bestView = getBestView(candidateViews, requestedMediaTypes, attrs); if (bestView != null) { return bestView; } } // 下面是异常逻辑处理 String mediaTypeInfo = logger.isDebugEnabled() && requestedMediaTypes != null ? " given " + requestedMediaTypes.toString() : ""; if (this.useNotAcceptableStatusCode) { if (logger.isDebugEnabled()) { logger.debug("Using 406 NOT_ACCEPTABLE" + mediaTypeInfo); } return NOT_ACCEPTABLE_VIEW; } else { logger.debug("View remains unresolved" + mediaTypeInfo); return null; } }
这里我们主要关心两点：getCandidateViews与getBestView。
获取候选View的逻辑如下所示，拿到能直接解析viewName的viewResolver解析后的View放入List candidateViews中。然后遍历requestedMediaTypes，根据一个个viewName + '.' + extension尝试找到viewResolver解析后的View放入candidateViews 中。
private List<View> getCandidateViews(String viewName, Locale locale, List<MediaType> requestedMediaTypes) throws Exception { List<View> candidateViews = new ArrayList<>(); if (this.viewResolvers != null) { Assert.state(this.contentNegotiationManager != null, "No ContentNegotiationManager set"); for (ViewResolver viewResolver : this.viewResolvers) { //如果能直接拿到View则放入candidateViews View view = viewResolver.resolveViewName(viewName, locale); if (view != null) { candidateViews.add(view); } // 根据requestedMediaType 的extensions -尝试找到viewResolver进行解析 for (MediaType requestedMediaType : requestedMediaTypes) { List<String> extensions = this.contentNegotiationManager.resolveFileExtensions(requestedMediaType); for (String extension : extensions) { String viewNameWithExtension = viewName + '.' + extension; view = viewResolver.resolveViewName(viewNameWithExtension, locale); if (view != null) { candidateViews.add(view); } } } } } // 如果defaultViews不为空，放入candidateViews if (!CollectionUtils.isEmpty(this.defaultViews)) { candidateViews.addAll(this.defaultViews); } return candidateViews; }
getBestView方法如下所示，先判断是否重定向View，如果是重定向View直接返回。然后对requestedMediaTypes和candidateViews进行遍历查找，找到一个ContentType合适的candidateView 返回，否则返回null。
@Nullable private View getBestView(List<View> candidateViews, List<MediaType> requestedMediaTypes, RequestAttributes attrs) { // 判断重定向View for (View candidateView : candidateViews) { if (candidateView instanceof SmartView) { SmartView smartView = (SmartView) candidateView; if (smartView.isRedirectView()) { return candidateView; } } } // 根据mediaType 和 ContentType进行比较筛选 for (MediaType mediaType : requestedMediaTypes) { for (View candidateView : candidateViews) { if (StringUtils.hasText(candidateView.getContentType())) { MediaType candidateContentType = MediaType.parseMediaType(candidateView.getContentType()); if (mediaType.isCompatibleWith(candidateContentType)) { if (logger.isDebugEnabled()) { logger.debug("Selected '" + mediaType + "' given " + requestedMediaTypes); } attrs.setAttribute(View.SELECTED_CONTENT_TYPE, mediaType, RequestAttributes.SCOPE_REQUEST); return candidateView; } } } } return null; }
【4】AbstractCachingViewResolver
除了ViewResolverComposite、ContentNegotiatingViewResolver以及BeanNameViewResolver外，其余视图解析器都是AbstractCachingViewResolver的子类。如下图所示其同样继承了WebApplicationObjectSupport实现类，也就意味着其实现了ApplicationContextAware和ServletContextAware接口。这两个接口意味着什么，这里不再赘述。
我们看其子类结构发现其子类仍然分为四类：
- ① org.thymeleaf.spring5.view体系的ThymeleafViewResolver
- ② XML结构处理的XmlViewResolver
- ③ 处理资源国际化的ResourceBundleViewResolver
- ④ 最常见的UrlBasedViewResolver
其提供了抽象方法loadView让子类实现，子类实现该方法返回一个View对象。AbstractCachingViewResolver会缓存子类返回的View对象放入private final Map viewAccessCache = new ConcurrentHashMap<>(DEFAULT_CACHE_LIMIT);中
@Nullable protected View createView(String viewName, Locale locale) throws Exception { return loadView(viewName, locale); } protected abstract View loadView(String viewName, Locale locale) throws Exception;
AbstractCachingViewResolver解析视图的方法
放入如下所示，首先判断是否存在缓存实例，不存在直接走创建View逻辑。如果有缓存实例，那么根据viewName获取cacheKey(viewName + '_' + locale;) ，先尝试从viewAccessCache中获取View，如果View为null，则进入锁方法块-尝试从viewCreationCache再次获取View，如果仍旧为null，则走创建逻辑。如果最终创建的View不为努力，则放入viewAccessCache和viewCreationCache。
@Override @Nullable public View resolveViewName(String viewName, Locale locale) throws Exception { // 如果没有缓存，直接走create逻辑 if (!isCache()) { return createView(viewName, locale); } else { // 如果有缓存，则拿到cacheKey 然后根据key获取对应的view Object cacheKey = getCacheKey(viewName, locale); View view = this.viewAccessCache.get(cacheKey); // 如果view为null，则加锁尝试创建view-联想双重校验锁？ if (view == null) { synchronized (this.viewCreationCache) { view = this.viewCreationCache.get(cacheKey); if (view == null) { // Ask the subclass to create the View object. view = createView(viewName, locale); if (view == null && this.cacheUnresolved) { view = UNRESOLVED_VIEW; } // 将创建后的view放入viewAccessCache与viewCreationCache if (view != null && this.cacheFilter.filter(view, viewName, locale)) { this.viewAccessCache.put(cacheKey, view); this.viewCreationCache.put(cacheKey, view); } } } } else { if (logger.isTraceEnabled()) { logger.trace(formatKey(cacheKey) + "served from cache"); } } return (view != UNRESOLVED_VIEW ? view : null); } }
【5】ThymeleafViewResolver
ThymeleafViewResolver将会解析视图返回一个ThymeleafView对象，ThymeleafView实现了render方法也就是视图渲染方法-将model与view结合起来，最后将信息写入到response中。
① 获取view
@Override protected View createView(final String viewName, final Locale locale) throws Exception { // First possible call to check "viewNames": before processing redirects and forwards if (!this.alwaysProcessRedirectAndForward && !canHandle(viewName, locale)) { vrlogger.trace("[THYMELEAF] View \"{}\" cannot be handled by ThymeleafViewResolver. Passing on to the next resolver in the chain.", viewName); return null; } // Process redirects (HTTP redirects) if (viewName.startsWith(REDIRECT_URL_PREFIX)) { vrlogger.trace("[THYMELEAF] View \"{}\" is a redirect, and will not be handled directly by ThymeleafViewResolver.", viewName); final String redirectUrl = viewName.substring(REDIRECT_URL_PREFIX.length(), viewName.length()); final RedirectView view = new RedirectView(redirectUrl, isRedirectContextRelative(), isRedirectHttp10Compatible()); return (View) getApplicationContext().getAutowireCapableBeanFactory().initializeBean(view, REDIRECT_URL_PREFIX); } // Process forwards (to JSP resources) if (viewName.startsWith(FORWARD_URL_PREFIX)) { // The "forward:" prefix will actually create a Servlet/JSP view, and that's precisely its aim per the Spring // documentation. See http://docs.spring.io/spring-framework/docs/4.2.4.RELEASE/spring-framework-reference/html/mvc.html#mvc-redirecting-forward-prefix vrlogger.trace("[THYMELEAF] View \"{}\" is a forward, and will not be handled directly by ThymeleafViewResolver.", viewName); final String forwardUrl = viewName.substring(FORWARD_URL_PREFIX.length(), viewName.length()); return new InternalResourceView(forwardUrl); } // Second possible call to check "viewNames": after processing redirects and forwards if (this.alwaysProcessRedirectAndForward && !canHandle(viewName, locale)) { vrlogger.trace("[THYMELEAF] View \"{}\" cannot be handled by ThymeleafViewResolver. Passing on to the next resolver in the chain.", viewName); return null; } vrlogger.trace("[THYMELEAF] View {} will be handled by ThymeleafViewResolver and a " + "{} instance will be created for it", viewName, getViewClass().getSimpleName()); return loadView(viewName, locale); }
这里很有意思，解释如下：
① 其首先判断是否能够处理viewName，不能处理直接返回null；
② REDIRECT_URL_PREFIX = "redirect:"判断是否为重定向view，如果是重定向view则截取viewName获得redirectUrl，创建RedirectView实例并进行其bean初始化过程；
③ FORWARD_URL_PREFIX = "forward:"判断是否为转发view，如果是转发View则截取viewName获取forwardUrl，返回一个InternalResourceView实例。
④ 如果alwaysProcessRedirectAndForward 被设置为true，但是不能处理当前viewName，返回null；
⑤ 使用ThymeleafViewResolver 解析viewName。loadView方法如下所示：
@Override protected View loadView(final String viewName, final Locale locale) throws Exception { final AutowireCapableBeanFactory beanFactory = getApplicationContext().getAutowireCapableBeanFactory(); final boolean viewBeanExists = beanFactory.containsBean(viewName); final Class<?> viewBeanType = viewBeanExists? beanFactory.getType(viewName) : null; final AbstractThymeleafView view; if (viewBeanExists && viewBeanType != null && AbstractThymeleafView.class.isAssignableFrom(viewBeanType)) { // AppCtx has a bean with name == viewName, and it is a View bean. So let's use it as a prototype! // // This can mean two things: if the bean has been defined with scope "prototype", we will just use it. // If it hasn't we will create a new instance of the view class and use its properties in order to // configure this view instance (so that we don't end up using the same bean from several request threads). // // Note that, if Java-based configuration is used, using @Scope("prototype") would be the only viable // possibility here. final BeanDefinition viewBeanDefinition = (beanFactory instanceof ConfigurableListableBeanFactory ? ((ConfigurableListableBeanFactory)beanFactory).getBeanDefinition(viewName) : null); if (viewBeanDefinition == null || !viewBeanDefinition.isPrototype()) { // No scope="prototype", so we will just apply its properties. This should only happen with XML config. final AbstractThymeleafView viewInstance = BeanUtils.instantiateClass(getViewClass()); view = (AbstractThymeleafView) beanFactory.configureBean(viewInstance, viewName); } else { // This is a prototype bean. Use it as such. view = (AbstractThymeleafView) beanFactory.getBean(viewName); } } else { final AbstractThymeleafView viewInstance = BeanUtils.instantiateClass(getViewClass()); if (viewBeanExists && viewBeanType == null) { // AppCtx has a bean with name == viewName, but it is an abstract bean. We still can use it as a prototype. // The AUTOWIRE_NO mode applies autowiring only through annotations beanFactory.autowireBeanProperties(viewInstance, AutowireCapableBeanFactory.AUTOWIRE_NO, false); // A bean with this name exists, so we apply its properties beanFactory.applyBeanPropertyValues(viewInstance, viewName); // Finally, we let Spring do the remaining initializations (incl. proxifying if needed) view = (AbstractThymeleafView) beanFactory.initializeBean(viewInstance, viewName); } else { // Either AppCtx has no bean with name == viewName, or it is of an incompatible class. No prototyping done. // The AUTOWIRE_NO mode applies autowiring only through annotations beanFactory.autowireBeanProperties(viewInstance, AutowireCapableBeanFactory.AUTOWIRE_NO, false); // Finally, we let Spring do the remaining initializations (incl. proxifying if needed) view = (AbstractThymeleafView) beanFactory.initializeBean(viewInstance, viewName); } } view.setTemplateEngine(getTemplateEngine()); view.setStaticVariables(getStaticVariables()); // We give view beans the opportunity to specify the template name to be used if (view.getTemplateName() == null) { view.setTemplateName(viewName); } if (!view.isForceContentTypeSet()) { view.setForceContentType(getForceContentType()); } if (!view.isContentTypeSet() && getContentType() != null) { view.setContentType(getContentType()); } if (view.getLocale() == null && locale != null) { view.setLocale(locale); } if (view.getCharacterEncoding() == null && getCharacterEncoding() != null) { view.setCharacterEncoding(getCharacterEncoding()); } if (!view.isProducePartialOutputWhileProcessingSet()) { view.setProducePartialOutputWhileProcessing(getProducePartialOutputWhileProcessing()); } return view; }
代码看起来比较长，其实核心就是获取Bean的实例然后进行bean的初始化过程最后设置诸如TemplateEngine、StaticVariables、TemplateName以及CharacterEncoding等属性。这里getViewClass返回的是ThymeleafView.class。也就是说该方法会返回一个ThymeleafView实例，除非你自定义实现类继承自AbstractThymeleafView。
【6】UrlBasedViewResolver
除去ThymeleafViewResolver(对应Thymeleaf)之外，我们最熟悉的可能就是InternalResourceViewResolver(对应JSP)和FreeMarkerViewResolver(对应Freemarker)了。
① UrlBasedViewResolver的重要属性
//重定向前缀 public static final String REDIRECT_URL_PREFIX = "redirect:"; // 转发前缀 public static final String FORWARD_URL_PREFIX = "forward:"; // 视图类型 @Nullable private Class<?> viewClass; // prefix="/WEB-INF/jsp/", suffix=".jsp", viewname="test" -> // "/WEB-INF/jsp/test.jsp" private String prefix = ""; private String suffix = ""; //view的contentType @Nullable private String contentType; //true表示重定向时相对于web application root private boolean redirectContextRelative = true; //true表示重定向时与HTTP 1.0 一致，如302；false则与HTTP 1.1一致，303 private boolean redirectHttp10Compatible = true; //重定向主机host @Nullable private String[] redirectHosts; //为view设置请求上下文中的属性 @Nullable private String requestContextAttribute; //Properties中的属性，你定义视图解析时的property /** Map of static attributes, keyed by attribute name (String). */ private final Map<String, Object> staticAttributes = new HashMap<>(); // 是否将path variables放到model里面，默认为null，让具体view决定 @Nullable private Boolean exposePathVariables; //是否能够作为请求属性访问spring容器中的bean，默认是false @Nullable private Boolean exposeContextBeansAsAttributes; //指定上下文中应该公开的bean的名称。如果该值为非null，则只有指定的bean有资格作为属性公开。 @Nullable private String[] exposedContextBeanNames; //设置能够被视图解析器处理的viewName @Nullable private String[] viewNames; //Integer.MAX_VALUE private int order = Ordered.LOWEST_PRECEDENCE;
为什么分析这些属性呢？我们看一下以前的一个配置实例：
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean>
② createView方法
createView覆盖了父类的createViewf方法。如下所示，方法分为四大块：
① 根据viewNames判断是否能够处理当前viewName;
② 处理重定向请求，获取一个RedirectView然后调用initializeBean方法进行初始化；
③ 处理转发请求，获取一个InternalResourceView，然后调用initializeBean方法进行初始化；
④ 调用父类的createView方法
@Override protected View createView(String viewName, Locale locale) throws Exception { // If this resolver is not supposed to handle the given view, // return null to pass on to the next resolver in the chain. if (!canHandle(viewName, locale)) { return null; } // Check for special "redirect:" prefix. if (viewName.startsWith(REDIRECT_URL_PREFIX)) { String redirectUrl = viewName.substring(REDIRECT_URL_PREFIX.length()); RedirectView view = new RedirectView(redirectUrl, isRedirectContextRelative(), isRedirectHttp10Compatible()); String[] hosts = getRedirectHosts(); if (hosts != null) { view.setHosts(hosts); } return applyLifecycleMethods(REDIRECT_URL_PREFIX, view); } // Check for special "forward:" prefix. if (viewName.startsWith(FORWARD_URL_PREFIX)) { String forwardUrl = viewName.substring(FORWARD_URL_PREFIX.length()); InternalResourceView view = new InternalResourceView(forwardUrl); return applyLifecycleMethods(FORWARD_URL_PREFIX, view); } // Else fall back to superclass implementation: calling loadView. return super.createView(viewName, locale); }
我们看下applyLifecycleMethods，如下所示调用BeanFactory的initializeBean方法对view进行初始化，核心步骤就是：
invokeAwareMethods applyBeanPostProcessorsBeforeInitialization invokeInitMethods applyBeanPostProcessorsAfterInitialization
protected View applyLifecycleMethods(String viewName, AbstractUrlBasedView view) { ApplicationContext context = getApplicationContext(); if (context != null) { Object initialized = context.getAutowireCapableBeanFactory().initializeBean(view, viewName); if (initialized instanceof View) { return (View) initialized; } } return view; }
③ loadView与buildView
loadView同样覆盖了父类的方法，如下所示委派buildView方法获取一个AbstractUrlBasedView 实例，然后调用其生命周期方法进行bean的初始化。
@Override protected View loadView(String viewName, Locale locale) throws Exception { AbstractUrlBasedView view = buildView(viewName); View result = applyLifecycleMethods(viewName, view); return (view.checkResource(locale) ? result : null); }
buildView方法如下所示，首先根据viewClass使用方法(AbstractUrlBasedView) BeanUtils.instantiateClass(viewClass)获取一个view实例。然后进行各种属性的赋值如url、properties、contentType等。
protected AbstractUrlBasedView buildView(String viewName) throws Exception { // 获取一个view实例 AbstractUrlBasedView view = instantiateView(); //如下都是属性的赋值 view.setUrl(getPrefix() + viewName + getSuffix()); view.setAttributesMap(getAttributesMap()); String contentType = getContentType(); if (contentType != null) { view.setContentType(contentType); } String requestContextAttribute = getRequestContextAttribute(); if (requestContextAttribute != null) { view.setRequestContextAttribute(requestContextAttribute); } Boolean exposePathVariables = getExposePathVariables(); if (exposePathVariables != null) { view.setExposePathVariables(exposePathVariables); } Boolean exposeContextBeansAsAttributes = getExposeContextBeansAsAttributes(); if (exposeContextBeansAsAttributes != null) { view.setExposeContextBeansAsAttributes(exposeContextBeansAsAttributes); } String[] exposedContextBeanNames = getExposedContextBeanNames(); if (exposedContextBeanNames != null) { view.setExposedContextBeanNames(exposedContextBeanNames); } return view; }
【7】InternalResourceViewResolver
该解析器处理viewName返回一个InternalResourceView或JstlView实例。当使用链式ViewResolvers时，InternalResourceViewResolver始终需要配置为最后一个，因为它将尝试解析任何视图名称，而不管底层资源是否实际存在。
① 构造函数
// 调用无参构造函数，设置前缀和后缀 public InternalResourceViewResolver(String prefix, String suffix) { this(); setPrefix(prefix); setSuffix(suffix); } //无参构造函数 public InternalResourceViewResolver() { // 默认返回InternalResourceView Class<?> viewClass = requiredViewClass(); if (InternalResourceView.class == viewClass && jstlPresent) { viewClass = JstlView.class; } setViewClass(viewClass); }
② 覆盖父类的instantiateView
方法如下所示，如果viewClass是InternalResourceViewz则new InternalResourceView();如果是JstlView，则获取一个JstlView实例；否则最后调用父类的instantiateView方法。
@Override protected AbstractUrlBasedView instantiateView() { return (getViewClass() == InternalResourceView.class ? new InternalResourceView() : (getViewClass() == JstlView.class ? new JstlView() : super.instantiateView())); }
③ 覆盖父类的buildView方法
这里调用了父类的buildView方法，然后做了两个增强：
alwaysInclude，指定是否始终包含视图而不是转发视图。默认值为“false”。打开此标志以强制使用Servlet包含，即使可以转发
preventDispatchLoop，设置是否显式阻止转发回当前处理程序路径。默认值为“false”。对于基于约定的视图，如果将其转发回当前处理程序路径是一个确定错误，请将其切换为“true”。
@Override protected AbstractUrlBasedView buildView(String viewName) throws Exception { InternalResourceView view = (InternalResourceView) super.buildView(viewName); if (this.alwaysInclude != null) { view.setAlwaysInclude(this.alwaysInclude); } view.setPreventDispatchLoop(true); return view; }
