Spring Web MVC 5.0.2详解：基于Servlet栈的Web开发框架

web

需积分: 9 27 浏览量更新于2024-07-18 收藏 4.05MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

Web on Servlet Stack 是一个关于基于Java Servlet技术构建Web应用程序的指南，特别是关注Spring Web MVC框架的版本5.0.2.RELEASE。此资源详细介绍了如何在Servlet容器（如Tomcat）中利用Spring MVC来实现高效的Web开发。 1. **Spring Web MVC介绍**： - Spring Web MVC是Spring框架的一部分，它提供了一种模型-视图-控制器（Model-View-Controller, MVC）的架构模式，将业务逻辑、数据处理和用户界面分离，使得开发可维护的Web应用更加高效。 2. **DispatcherServlet核心组件**： - DispatcherServlet负责接收HTTP请求并根据配置转发到合适的控制器方法。 - **ContextHierarchy**：每个请求都会创建一个上下文，包括应用上下文、 DispatcherServlet上下文和视图解析上下文，用于处理请求的生命周期。 - **特殊Bean类型**：如国际化（Locale）、时区管理、header解析器等，都是为了增强应用程序的国际化和响应式设计。 - **配置管理**：包括框架配置（如启用或禁用国际化）、容器配置（如设置默认的视图解析器）等。 3. **请求处理与控制流**： - **Redirect** 和 **Forward** 是两种常见的请求处理方式，Redirect用于重定向到另一个URL，而Forward则是将请求转发到同域下的其他控制器方法。 - **内容协商**：支持根据客户端请求自动选择合适的媒体类型，如定义主题、解析multipart requests（文件上传）。 4. **Servlet 3.0兼容性**： - 该指南强调了对Servlet 3.0标准的支持，包括HTTP PUT方法处理、处理Forwarded请求头、浅层Etag处理以及CORS（跨源资源共享）。 5. **过滤器**： - 过滤器在Spring MVC中扮演辅助角色，例如处理PUT请求、处理Forwarded请求头、处理浅层Etags，以及实现CORS策略。 - **Annotated Controllers**：Spring Web MVC允许通过注解声明控制器和方法，简化了MVC架构的使用。 6. **注解和AOP**： - Annotated Controllers利用注解进行方法声明，比如@RequestMapping用于映射HTTP请求到控制器方法，AOP（面向切面编程）支持通过代理机制实现声明式事务管理、日志等。 7. **请求处理细节**： - URI pattern matching（路径匹配）和参数处理，如矩阵变量、consumable media types（可消费的媒体类型）和producible media types（可生产的媒体类型），都对控制器方法的选择起到关键作用。 - HTTP HEAD和OPTIONS方法的特殊处理，以及如何处理方法参数、返回值类型转换等。 Web on Servlet Stack文档深入讲解了如何利用Spring Web MVC构建高性能、可扩展的Web应用，涵盖了从基础概念到高级特性的全面指导，对于Java Web开发者来说是一份实用的参考资源。

资源详情

资源推荐

1.2.4. Container Config

In a Servlet 3.0+ environment, you have the option of configuring the Servlet container

programmatically as an alternative or in combination with a web.xml file. Below is an example of

registering a DispatcherServlet:

import org.springframework.web.WebApplicationInitializer;

public class MyWebApplicationInitializer implements WebApplicationInitializer {

Ê @Override

Ê public void onStartup(ServletContext container) {

Ê XmlWebApplicationContext appContext = new XmlWebApplicationContext();

Ê appContext.setConfigLocation("/WEB-INF/spring/dispatcher-config.xml");

Ê ServletRegistration.Dynamic registration = container.addServlet("dispatcher",

new DispatcherServlet(appContext));

Ê registration.setLoadOnStartup(1);

Ê registration.addMapping("/");

Ê }

}

WebApplicationInitializer is an interface provided by Spring MVC that ensures your

implementation is detected and automatically used to initialize any Servlet 3 container. An abstract

base class implementation of WebApplicationInitializer named

AbstractDispatcherServletInitializer makes it even easier to register the DispatcherServlet by

simply overriding methods to specify the servlet mapping and the location of the DispatcherServlet

configuration.

This is recommended for applications that use Java-based Spring configuration:

public class MyWebAppInitializer extends AbstractDispatcherServletInitializer {

Ê // ...

Ê @Override

Ê protected Filter[] getServletFilters() {

Ê return new Filter[] {

Ê new HiddenHttpMethodFilter(), new CharacterEncodingFilter() };

Ê }

}

Each filter is added with a default name based on its concrete type and automatically mapped to

the DispatcherServlet.

The isAsyncSupported protected method of AbstractDispatcherServletInitializer provides a single

place to enable async support on the DispatcherServlet and all filters mapped to it. By default this

flag is set to true.

Finally, if you need to further customize the DispatcherServlet itself, you can override the

createDispatcherServlet method.

1.2.5. Processing

Same in Spring WebFlux

The DispatcherServlet processes requests as follows:

• The WebApplicationContext is searched for and bound in the request as an attribute that the

controller and other elements in the process can use. It is bound by default under the key

DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE.

• The locale resolver is bound to the request to enable elements in the process to resolve the

locale to use when processing the request (rendering the view, preparing data, and so on). If you

do not need locale resolving, you do not need it.

• The theme resolver is bound to the request to let elements such as views determine which

theme to use. If you do not use themes, you can ignore it.

• If you specify a multipart file resolver, the request is inspected for multiparts; if multiparts are

found, the request is wrapped in a MultipartHttpServletRequest for further processing by other

elements in the process. See Multipart requests for further information about multipart

handling.

• An appropriate handler is searched for. If a handler is found, the execution chain associated

with the handler (preprocessors, postprocessors, and controllers) is executed in order to

prepare a model or rendering. Or alternatively for annotated controllers, the response may be

rendered (within the HandlerAdapter) instead of returning a view.

• If a model is returned, the view is rendered. If no model is returned, (may be due to a

preprocessor or postprocessor intercepting the request, perhaps for security reasons), no view

is rendered, because the request could already have been fulfilled.

The HandlerExceptionResolver beans declared in the WebApplicationContext are used to resolve

exceptions thrown during request processing. Those exception resolvers allow customizing the

logic to address exceptions. See Exception Handling for more details.

The Spring DispatcherServlet also supports the return of the last-modification-date, as specified by

the Servlet API. The process of determining the last modification date for a specific request is

straightforward: the DispatcherServlet looks up an appropriate handler mapping and tests whether

the handler that is found implements the LastModified interface. If so, the value of the long

getLastModified(request) method of the LastModified interface is returned to the client.

You can customize individual DispatcherServlet instances by adding Servlet initialization

parameters ( init-param elements) to the Servlet declaration in the web.xml file. See the following

table for the list of supported parameters.

Table 1. DispatcherServlet initialization parameters

Parameter Explanation

contextClass

Class that implements WebApplicationContext,

which instantiates the context used by this

Servlet. By default, the XmlWebApplicationContext

is used.

contextConfigLocation

String that is passed to the context instance

(specified by contextClass) to indicate where

context(s) can be found. The string consists

potentially of multiple strings (using a comma as

a delimiter) to support multiple contexts. In case

of multiple context locations with beans that are

defined twice, the latest location takes

precedence.

namespace

Namespace of the WebApplicationContext.

Defaults to [servlet-name]-servlet.

1.2.6. Interception

All HandlerMapping implementations supports handler interceptors that are useful when you want to

apply specific functionality to certain requests, for example, checking for a principal. Interceptors

must implement HandlerInterceptor from the org.springframework .web .servlet package with

three methods that should provide enough flexibility to do all kinds of pre-processing and post-

processing:

• preHandle(..) — before the actual handler is executed

• postHandle(..) — after the handler is executed

• afterCompletion(..) — after the complete request has finished

The preHandle(..) method returns a boolean value. You can use this method to break or continue

the processing of the execution chain. When this method returns true, the handler execution chain

will continue; when it returns false, the DispatcherServlet assumes the interceptor itself has taken

care of requests (and, for example, rendered an appropriate view) and does not continue executing

the other interceptors and the actual handler in the execution chain.

See Interceptors in the section on MVC configuration for examples of how to configure interceptors.

You can also register them directly via setters on individual HandlerMapping implementations.

Note that postHandle is less useful with @ResponseBody and ResponseEntity methods for which a the

response is written and committed within the HandlerAdapter and before postHandle. That means its

too late to make any changes to the response such as adding an extra header. For such scenarios

you can implement ResponseBodyAdvice and either declare it as an Controller Advice bean or

configure it directly on RequestMappingHandlerAdapter.

1.2.7. View Resolution

Spring MVC defines the ViewResolver and View interfaces that enable you to render models in a

browser without tying you to a specific view technology. ViewResolver provides a mapping between

view names and actual views. View addresses the preparation of data before handing over to a

specific view technology.

This table below provides more details on the ViewResolver hierarchy:

Table 2. ViewResolver implementations

ViewResolver Description

AbstractCachingViewResolver

Sub-classes of AbstractCachingViewResolver

cache view instances that they resolve. Caching

improves performance of certain view

technologies. It’s possible to turn off the cache

by setting the cache property to false.

Furthermore, if you must refresh a certain view

at runtime (for example when a FreeMarker

template is modified), you can use the

removeFromCache(String viewName, Locale loc)

method.

XmlViewResolver

Implementation of ViewResolver that accepts a

configuration file written in XML with the same

DTD as Spring’s XML bean factories. The default

configuration file is /WEB-INF/views.xml.

ResourceBundleViewResolver

Implementation of ViewResolver that uses bean

definitions in a ResourceBundle, specified by the

bundle base name, and for each view it is

supposed to resolve, it uses the value of the

property [viewname].(class) as the view class

and the value of the property [viewname].url as

the view url. Examples can be found in the

chapter on View Technologies.

UrlBasedViewResolver

Simple implementation of the ViewResolver

interface that effects the direct resolution of

logical view names to URLs, without an explicit

mapping definition. This is appropriate if your

logical names match the names of your view

resources in a straightforward manner, without

the need for arbitrary mappings.

剩余186页未读，继续阅读

milesandnick

粉丝: 6
资源: 24

Spring Web MVC 5.0.2详解：基于Servlet栈的Web开发框架

servlet2.4doc

Spring 5.0 web 官方文档 转PDF

基于CFX开发WebService

exception on invalid stack

WebStack-Laravel

DECLARE_COMPLETION_ONSTACK

WebStack-Hugo

严重性 代码 说明 项目 文件 行 禁止显示状态 错误 C2338 OBJECT_ALLOCATED_ON_STACK_IS_TOO_BIG testOpenCV d:\3rdplib\eigen3\eigen\src\core\densestorage.h 33

WebStack使用

stack<string> s

• Design a Stack class (Eg 8 9 w) When the element pushed into the stack exceeds the capacity of the stack, it will throw a stack-full exception; When pop an element out of the stack when the stack is full, it will throw a stack-empty exception.

MinStack minStack = new MinStack();

typedef struct stack *stack; 中*stack的含义

Redis Stack 和 Redis Stack Server

//file name stack.h #define STACK_SIZE 50 typedef struct stack { int DATA[STACK_SIZE]; int TOP; //栈顶指针 }STACK; int stack_push(STACK *S,int data); int stack_pop(STACK *S);什么意思

struct stack* stack1 = (struct stack*)malloc(sizeof(stack));

最新资源

Spring 5.0 web 官方文档转PDF

严重性代码说明项目文件行禁止显示状态错误 C2338 OBJECT_ALLOCATED_ON_STACK_IS_TOO_BIG testOpenCV d:\3rdplib\eigen3\eigen\src\core\densestorage.h 33

typedef struct stack stack; 中stack的含义

//file name stack.h #define STACK_SIZE 50 typedef struct stack { int DATA[STACK_SIZE]; int TOP; //栈顶指针 }STACK; int stack_push(STACK S,int data); int stack_pop(STACK S);什么意思