1.1 DispatcherServlet
与其他许多Web框架一样,Spring MVC围绕前端控制器模式进行设计,在该模式下,中央Servlet DispatcherServlet提供了用于请求处理的共享算法,而实际工作是由可配置的委托组件执行的。 该模型非常灵活,并支持多种工作流程。
与任何Servlet一样,都需要根据Servlet规范使用Java配置或在web.xml中声明和映射DispatcherServlet。 反过来,DispatcherServlet使用Spring配置发现请求映射,视图解析,异常处理等所需的委托组件。
以下Java配置示例注册并初始化DispatcherServlet,该容器由Servlet容器自动检测到(请参阅Servlet Config):
除了直接使用ServletContext API外,您还可以扩展AbstractAnnotationConfigDispatcherServletInitializer并覆盖特定方法(请参见Context Hierarchy下的示例)。
以下web.xml配置示例注册并初始化DispatcherServlet:
Spring Boot遵循不同的初始化顺序。 Spring Boot并没有陷入Servlet容器的生命周期,而是使用Spring配置来引导自身和嵌入式Servlet容器。 在Spring配置中检测到过滤器和Servlet声明,并在Servlet容器中注册。 有关更多详细信息,请参见Spring Boot文档。
1.1.1 Context 层级关系
DispatcherServlet期望WebApplicationContext(纯ApplicationContext的扩展)为其自身的配置。 WebApplicationContext具有指向ServletContext和与其关联的Servlet的链接。它还绑定到ServletContext,以便应用程序可以在RequestContextUtils上使用静态方法来查找WebApplicationContext(如果需要访问它们)。
对于许多应用程序而言,拥有一个WebApplicationContext很简单并且足够。也可能具有上下文层次结构,其中一个根WebApplicationContext在多个DispatcherServlet(或其他Servlet)实例之间共享,每个实例都有其自己的子WebApplicationContext配置。有关上下文层次结构功能的更多信息,请参见ApplicationContext的其他功能。
根WebApplicationContext通常包含需要在多个Servlet实例之间共享的基础结构Bean,例如数据存储库和业务服务。这些Bean是有效继承的,并且可以在Servlet特定的子WebApplicationContext中重写(即重新声明),该子WebApplicationContext通常包含给定Servlet本地的Bean。下图显示了这种关系:
下面的示例配置一个WebApplicationContext层次结构:
如果不需要应用程序上下文层次结构,则应用程序可以通过getRootConfigClasses()返回所有配置,并从getServletConfigClasses()返回null。
以下示例显示了web.xml等效项:
如果不需要应用程序上下文层次结构,则应用程序可以仅配置“根”上下文,并将contextConfigLocation Servlet参数保留为空。
1.1.2 特殊bean类型
DispatcherServlet委托给特殊的Bean处理请求并呈现适当的响应。 所谓“特殊bean”,是指实现框架协定的Spring管理对象实例。 这些通常带有内置合同,但是您可以自定义它们的属性并扩展或替换它们。
下表列出了DispatcherServlet检测到的特殊bean:
1.1.3 Web MVC Config
应用程序可以声明处理请求所需的特殊Bean类型中列出的基础结构Bean。 DispatcherServlet检查每个特殊bean的WebApplicationContext。 如果没有匹配的bean类型,它将使用DispatcherServlet.properties中列出的默认类型。
在大多数情况下,MVC Config是最佳起点。 它使用Java或XML声明所需的bean,并提供了更高级别的配置回调API来对其进行自定义。
1.1.4 Servlet Config
在Servlet 3.0+环境中,您可以选择以编程方式配置Servlet容器,作为替代方案或与web.xml文件结合使用。 下面的示例注册一个DispatcherServlet:
WebApplicationInitializer是Spring MVC提供的接口,可确保检测到您的实现并将其自动用于初始化任何Servlet 3容器。 WebApplicationInitializer的抽象基类实现名为AbstractDispatcherServletInitializer,它通过重写指定Servlet映射和DispatcherServlet配置位置的方法,使注册DispatcherServlet更容易。
对于使用基于Java的Spring配置的应用程序,建议这样做,如以下示例所示:
如果使用基于XML的Spring配置,则应直接从AbstractDispatcherServletInitializer进行扩展,如以下示例所示:
AbstractDispatcherServletInitializer还提供了一种方便的方法来添加Filter实例,并将其自动映射到DispatcherServlet,如以下示例所示:
每个过滤器都会根据其具体类型添加一个默认名称,并自动映射到DispatcherServlet。
AbstractDispatcherServletInitializer的isAsyncSupported受保护方法提供了一个位置,以在DispatcherServlet及其映射的所有过滤器上启用异步支持。 默认情况下,此标志设置为true。
最后,如果您需要进一步自定义DispatcherServlet本身,则可以覆盖createDispatcherServlet方法。
1.1.5 Processing
DispatcherServlet处理请求的方式如下:
搜索WebApplicationContext并将其绑定在请求中,作为控制器和流程中其他元素可以使用的属性。默认情况下,它绑定在DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE键下。
语言环境解析器绑定到请求,以使流程中的元素解析在处理请求(呈现视图,准备数据等)时要使用的语言环境。如果不需要语言环境解析,则不需要语言环境解析器。
主题解析器绑定到请求,以使诸如视图之类的元素确定要使用的主题。如果不使用主题,则可以将其忽略。
如果指定多部分文件解析器,则将检查请求中是否有多部分。如果找到多部分,则将该请求包装在MultipartHttpServletRequest中,以供流程中的其他元素进一步处理。有关多部分处理的更多信息,请参见Multipart Resolver。
搜索适当的处理程序。如果找到处理程序,则执行与处理程序(预处理器,后处理器和控制器)关联的执行链,以准备模型或渲染。或者,对于带注解的控制器,可以呈现响应(在HandlerAdapter中),而不是返回视图。
如果返回模型,则呈现视图。如果没有返回任何模型(可能是由于预处理器或后处理器拦截了该请求,可能出于安全原因),则不会呈现任何视图,因为该请求可能已经被满足。
WebApplicationContext中声明的HandlerExceptionResolver Bean用于解决在请求处理期间引发的异常。这些异常解析器允许定制逻辑以解决异常。有关更多详细信息,请参见异常。
Spring DispatcherServlet还支持Servlet API所指定的last-modification-date的返回。确定特定请求的最后修改日期的过程很简单:DispatcherServlet查找适当的处理程序映射,并测试找到的处理程序是否实现了LastModified接口。如果是这样,则将LastModified接口的long getLastModified(request)方法的值返回给客户端。
您可以通过将Servlet初始化参数(init-param元素)添加到web.xml文件中的Servlet声明中,来定制各个DispatcherServlet实例。下表列出了受支持的参数:
1.1.6 Interception
所有HandlerMapping实现都支持处理程序拦截器,当您要将特定功能应用于某些请求时(例如,检查主体),该拦截器很有用。拦截器必须使用三种方法从org.springframework.web.servlet包中实现HandlerInterceptor,这三种方法应提供足够的灵活性来执行各种预处理和后处理:
preHandle(..):在执行实际处理程序之前
postHandle(..):处理程序执行后
afterCompletion(..):在完成请求之后
preHandle(..)方法返回一个布尔值。您可以使用此方法来中断或继续执行链的处理。当此方法返回true时,处理程序执行链将继续。当它返回false时,DispatcherServlet假定拦截器本身已经处理了请求(例如,渲染了一个适当的视图),并且不会继续执行其他拦截器和执行链中的实际处理程序。
有关如何配置拦截器的示例,请参见MVC配置部分中的拦截器。您还可以通过在各个HandlerMapping实现上使用setter直接注册它们。
请注意,对于@ResponseBody和ResponseEntity方法,postHandle的用处不大,在HandlerAdapter内以及postHandle之前,将其写入并提交响应。这意味着对响应进行任何更改为时已晚,例如添加额外的标头。对于这种情况,您可以实现ResponseBodyAdvice并将其声明为Controller Advice Bean或直接在RequestMappingHandlerAdapter上对其进行配置。
1.1.7 Exceptions
如果异常在请求映射期间发生或从请求处理程序(例如@Controller)抛出,则DispatcherServlet委托给HandlerExceptionResolver Bean链来解决该异常并提供替代处理,通常是错误响应。
下表列出了可用的HandlerExceptionResolver实现:
解析器链
您可以通过在Spring配置中声明多个HandlerExceptionResolver bean并根据需要设置其order属性来形成异常解析器链。 order属性越高,异常解析器的定位就越晚。
HandlerExceptionResolver的约定指定它可以返回:
指向错误视图的ModelAndView。
如果在解析程序中处理了异常,则为空的ModelAndView。
如果该异常仍未解决,则为null,以供后续解析器尝试;如果该异常仍在末尾,则允许将其冒泡到Servlet容器。
MVC Config自动为默认的Spring MVC异常,@ResponseStatus注解的异常以及对@ExceptionHandler方法的支持声明内置解析器。您可以自定义该列表或替换它。
容器错误页面
如果任何HandlerExceptionResolver都无法解决异常,因此该异常可以传播,或者如果响应状态设置为错误状态(即4xx,5xx),则Servlet容器可以在HTML中呈现默认错误页面。要自定义容器的默认错误页面,可以在web.xml中声明错误页面映射。以下示例显示了如何执行此操作:
给定前面的示例,当异常冒出或响应具有错误状态时,Servlet容器在容器内向配置的URL(例如/ error)进行ERROR调度。 然后由DispatcherServlet处理它,可能将其映射到@Controller,可以实现该错误以使用模型返回错误视图名称或呈现JSON响应,如以下示例所示:
Servlet API没有提供在Java中创建错误页面映射的方法。 但是,您可以同时使用WebApplicationInitializer和最小的web.xml。
1.1.8 View解析
Spring MVC定义了ViewResolver和View接口,这些接口使您可以在浏览器中呈现模型,而无需将您与特定的视图技术联系在一起。 ViewResolver提供了视图名称和实际视图之间的映射。 在移交给特定的视图技术之前,视图解决了数据准备问题。
下表提供了有关ViewResolver层次结构的更多详细信息:
Handling
您可以通过声明多个解析器bean,并在必要时通过设置order属性以指定顺序来链接视图解析器。 请记住,order属性越高,视图解析器在链中的定位就越晚。
ViewResolver的协定指定它可以返回null,以指示找不到该视图。 但是,对于JSP和InternalResourceViewResolver,确定JSP是否存在的唯一方法是通过RequestDispatcher进行调度。 因此,您必须始终将InternalResourceViewResolver配置为在视图解析器的总体顺序中排在最后。
配置视图分辨率就像将ViewResolver bean添加到Spring配置中一样简单。 MVC Config为View解析器和添加无逻辑的View Controller提供了专用的配置API,这对于无需控制器逻辑的HTML模板呈现非常有用。
Redirecting
视图名称中的特殊redirect:前缀使您可以执行重定向。 UrlBasedViewResolver(及其子类)将其识别为需要重定向的指令。 视图名称的其余部分是重定向URL。
最终效果与控制器返回RedirectView的效果相同,但是现在控制器本身可以根据逻辑视图名称进行操作。 逻辑视图名称(例如redirect:/ myapp / some / resource)相对于当前Servlet上下文进行重定向,而名称诸如redirect:https://myhost.com/some/arbitrary/path则重定向到绝对URL。
请注意,如果使用@ResponseStatus注解控制器方法,则注解值优先于RedirectView设置的响应状态。
Forwarding
您还可以使用特殊的forward:前缀表示最终由UrlBasedViewResolver和子类解析的视图名称。 这将创建一个InternalResourceView,它执行RequestDispatcher.forward()。 因此,此前缀在InternalResourceViewResolver和InternalResourceView(对于JSP)中没有用,但是如果您使用另一种视图技术但仍然希望强制转发由Servlet / JSP引擎处理的资源,则该前缀很有用。 请注意,您也可以链接多个视图解析器。
Content Negotiation
ContentNegotiatingViewResolver不会解析视图本身,而是委派给其他视图解析器,并选择类似于客户端请求的表示形式的视图。可以从Accept标头或查询参数(例如,“ / path?format = pdf”)中确定表示形式。
ContentNegotiatingViewResolver通过将请求媒体类型与其与每个ViewResolvers关联的View支持的媒体类型(也称为Content-Type)进行比较,从而选择合适的View处理该请求。列表中具有兼容Content-Type的第一个View将表示形式返回给客户端。如果ViewResolver链无法提供兼容的视图,请查阅通过DefaultViews属性指定的视图列表。后一个选项适用于单身视图,无论逻辑视图名称如何,该视图都可以呈现当前资源的适当表示形式。 Accept标头可以包含通配符(例如text / *),在这种情况下,其Content-Type为text / xml的View是兼容的匹配。
1.1.9 Locale
正如Spring Web MVC框架所做的那样,Spring体系结构的大多数部分都支持国际化。使用DispatcherServlet,您可以使用客户端的语言环境自动解析消息。这是通过LocaleResolver对象完成的。
当请求进入时,DispatcherServlet会寻找一个语言环境解析器,如果找到了它,它会尝试使用它来设置语言环境。通过使用RequestContext.getLocale()方法,您始终可以检索由语言环境解析器解析的语言环境。
除了自动的语言环境解析之外,您还可以在处理程序映射上附加一个拦截器(有关处理程序映射拦截器的更多信息,请参见拦截),以在特定情况下(例如,基于请求中的参数)更改语言环境。
语言环境解析器和拦截器在org.springframework.web.servlet.i18n包中定义,并以常规方式在应用程序上下文中进行配置。 Spring包含以下选择的语言环境解析器。
Time Zone
除了获取客户的语言环境外,了解其时区通常也很有用。 LocaleContextResolver接口提供了LocaleResolver的扩展,该扩展使解析程序可以提供更丰富的LocaleContext,其中可能包含时区信息。
如果可用,可以使用RequestContext.getTimeZone()方法获取用户的TimeZone。通过Spring的ConversionService注册的任何日期/时间转换器和格式器对象都会自动使用时区信息。
Header Resolver
该语言环境解析器检查客户端(例如,Web浏览器)发送的请求中的accept-language标头。通常,此标头字段包含客户端操作系统的语言环境。请注意,此解析器不支持时区信息。
Cookie Resolver
此语言环境解析器检查客户端上可能存在的Cookie,以查看是否指定了语言环境或TimeZone。如果是这样,它将使用指定的详细信息。通过使用此语言环境解析器的属性,可以指定Cookie的名称以及最长期限。以下示例定义了CookieLocaleResolver:
下面是CookieLocaleResolver的属性描述:
Session Resolver
通过SessionLocaleResolver,您可以从可能与用户请求关联的会话中检索Locale和TimeZone。与CookieLocaleResolver相比,此策略将本地选择的语言环境设置存储在Servlet容器的HttpSession中。结果,这些设置对于每个会话都是临时的,因此在每个会话终止时会丢失。
请注意,与外部会话管理机制(例如Spring Session项目)没有直接关系。此SessionLocaleResolver针对当前HttpServletRequest评估并修改相应的HttpSession属性。
Locale Interceptor
您可以通过将LocaleChangeInterceptor添加到HandlerMapping定义之一来启用语言环境更改。它检测请求中的参数并相应地更改语言环境,在调度程序的应用程序上下文中在LocaleResolver上调用setLocale方法。下一个示例显示对包含名为siteLanguage的参数的所有* .view资源的调用现在会更改语言环境。因此,例如,对URL的请求https://www.sf.net/home.view?siteLanguage=nl会将站点语言更改为荷兰语。以下示例显示如何拦截语言环境:
1.1.10 Themes
您可以应用Spring Web MVC框架主题来设置应用程序的整体外观,从而增强用户体验。主题是静态资源的集合,通常影响样式表和图像,这些样式表和图像会影响应用程序的视觉样式。
定义主题
要在Web应用程序中使用主题,您必须设置org.springframework.ui.context.ThemeSource接口的实现。 WebApplicationContext接口扩展了ThemeSource,但将其职责委托给专用的实现。默认情况下,委托是org.springframework.ui.context.support.ResourceBundleThemeSource实现,该实现从类路径的根加载属性文件。要使用自定义ThemeSource实现或配置ResourceBundleThemeSource的基本名称前缀,可以在应用程序上下文中使用保留名称themeSource注册Bean。 Web应用程序上下文会自动检测到具有该名称的bean并使用它。
当您使用ResourceBundleThemeSource时,将在一个简单的属性文件中定义一个主题。属性文件列出了组成主题的资源,如以下示例所示:
属性的键是从视图代码引用主题元素的名称。 对于JSP,通常使用spring:theme定制标记来执行此操作,该标记与spring:message标记非常相似。 以下JSP片段使用上一个示例中定义的主题来自定义外观:
默认情况下,ResourceBundleThemeSource使用一个空的基本名称前缀。 结果,从类路径的根加载属性文件。 因此,您可以将cool.properties主题定义放在类路径的根目录中(例如,在/ WEB-INF / classes中)。 ResourceBundleThemeSource使用标准的Java资源束加载机制,允许主题的完全国际化。 例如,我们可以有一个/WEB-INF/classes/cool_nl.properties,它引用带有荷兰文字的特殊背景图像。
Resolving Themes
定义主题后,如上一节所述,您可以决定要使用哪个主题。 DispatcherServlet查找一个名为themeResolver的bean,以找出要使用的ThemeResolver实现。 主题解析器的工作方式与LocaleResolver几乎相同。 它可以检测用于特定请求的主题,还可以更改请求的主题。 下表描述了Spring提供的主题解析器:
Spring还提供了ThemeChangeInterceptor,可以使用简单的请求参数对每个请求进行主题更改。
1.1.11 Multipart Resolver
org.springframework.web.multipart包中的MultipartResolver是一种用于解析包括文件上传在内的多部分请求的策略。有一种基于Commons FileUpload的实现,另一种基于Servlet 3.0多部分请求解析。
要启用多部分处理,您需要在DispatcherServlet Spring配置中声明一个名为multipartResolver的MultipartResolver bean。 DispatcherServlet会检测到它并将其应用于传入的请求。当收到内容类型为multipart / form-data的POST时,解析程序将解析内容并将当前的HttpServletRequest包装为MultipartHttpServletRequest,以提供对已解析部分的访问权,此外还可以将其公开为请求参数。
Apache Commons FileUpload
要使用Apache Commons FileUpload,可以配置名称为multipartResolver的CommonsMultipartResolver类型的Bean。您还需要commons-fileupload作为对类路径的依赖。
Servlet 3.0
需要通过Servlet容器配置启用Servlet 3.0多部分解析。为此:
在Java中,在Servlet注册上设置MultipartConfigElement。
在web.xml中,将“ <multipart-config>”部分添加到Servlet声明中。
以下示例显示了如何在Servlet注册上设置MultipartConfigElement:
Servlet 3.0配置到位后,您可以添加名称为multipartResolver的StandardServletMultipartResolver类型的Bean。
1.1.12 Logging
Spring MVC中的DEBUG级别的日志被设计为紧凑,最少且人性化的。 它侧重于一遍又一遍有用的高价值信息,而其他信息仅在调试特定问题时才有用。
TRACE级别的日志记录通常遵循与DEBUG相同的原则(例如,也不应是消防水带),但可用于调试任何问题。 此外,某些日志消息在TRACE和DEBUG上可能显示不同级别的详细信息。
良好的日志记录来自使用日志的经验。 如果您发现任何不符合既定目标的东西,请告诉我们。
敏感数据
调试和跟踪日志记录可能会记录敏感信息。 这就是默认情况下屏蔽请求参数和标头,并且必须通过DispatcherServlet上的enableLoggingRequestDetails属性显式启用它们的完整登录的原因。
以下示例显示了如何通过使用Java配置来执行此操作:
最后更新于