Spring文档Snippets

InternalResourceViewResovler需要放在视图解析器链的最后

原文链接

你可以通过定义多于一个的解析器Bean来形成ViewResolver链，并且如果有必要的话，设置order属性来指定它们的顺序。记住，order属性越高，视图解析器在链中的位置就越靠后。

ViewResolver的约定中定义了它可以通过返回null来指示没有找到对应的View。然而，在JSP和InternalResourceViewResovler中，我们只能通过让RequestDispatcher来实际执行一次分派这一种办法来了解一个JSP是否存在。因此，你必须始终将InternalResourceViewResovler配置在所有视图解析器之后。

解析：上面所要阐述的就是，由于种种限制，InternalResourceViewResolver必须尝试解析任何的视图名，而不管底层的文件是否存在，所以他永远都不会返回null。如果你将它放到视图处理器链的前面，其它视图处理器将没有机会执行。

你可以利用的两个MultipartResovler

原文链接

org.springframework.web.multipart包下的MultipartResolver口是解析包含文件上传的multipart请求的策略接口。有两个具体的策略实现，一个实现基于Apache的Commons FileUpload，另一个基于Servlet3.0中（自带）的multipart请求解析。

解析：SpringMVC利用策略模式来实现文件上传，它定义了策略接口MultipartResovler，而我们目前有两个实现可以利用，分别是Apache的和Servlet3中自带的。使用Apache的需要导包并定义CommonsMultipartResolver，使用Servlet3的需要保证Servlet版本大于等于3，设置DispatcherServlet的MultipartConfig，并且定义StandardServletMultipartResolver。

Controller默认参数解析逻辑

原文链接

如果一个方法参数没有匹配在这个表格中的前面的任何值，并且它是一个简单类型，那么它被@RequestParam注解来解析，否则，它被@ModelAttribute注解解析。

解析：在Controller方法中可以接收一些特殊参数，比如HttpServletRequest，HttpEntity，详情在官方文档中的一个表格里。但如果一个参数不是表格里定义的，如果它是一个简单类型（BeanUtils.isSimpleProperty），那它会按照@RequestParam的逻辑来解析，否则它会按照@ModelAttribute的逻辑来解析。也就是说，这两个注解可以省略。

标签：解析器,定义,Spring,视图,文档,multipart,Apache,解析,Snippets
来源： https://www.cnblogs.com/lilpig/p/16514630.html