亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

SpringMVC4.3解析器HandlerMethodArgumentResolver接口源碼

 更新時間:2023年09月11日 16:46:05   作者:愛吃魚的KK  
這篇文章主要為大家介紹了SpringMVC4.3解析器HandlerMethodArgumentResolver接口源碼解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪

HandlerMethodArgumentResolver 概述

HandlerMethodArgumentResolver = HandlerMethod + Argument(參數) + Resolver(解析器), 其實就是HandlerMethod方法的解析器, 將 HttpServletRequest(header + body 中的內容)解析為HandlerMethod方法的參數, 主要的策略接口如下:

// HandlerMethod 方法中 參數解析器
public interface HandlerMethodArgumentResolver {
    // 判斷 HandlerMethodArgumentResolver 是否支持 MethodParameter(PS: 一般都是通過 參數上面的注解|參數的類型)
    boolean supportsParameter(MethodParameter parameter);
    // 從 ModelAndViewContainer(被 @ModelAttribute), NativeWebRequest(其實就是HttpServletRequest) 中獲取數據, 解決 方法上的參數
    Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception;
}

基于這個接口實現(xiàn)的處理器主要是如下幾類:

1. 基于 Name 從 URI Template Variable, HttpServletRequest, HttpSession, Http 的 Header 中獲取數據的 HandlerMethodArgumentResolver
2. 數據類型是 Map 的 HandlerMethodArgumentResolver(數據也是從 RI Template Variable, HttpServletRequest, HttpSession, Http 的 Header 中獲取)
3. 固定參數類型的 HandlerMethodArgumentResolver, 這里的參數比如是 SessionStatus, ServletResponse, OutputStream, Writer, WebRequest, MultipartRequest, HttpSession, Principal, InputStream 等
4. 基于 ContentType 利用 HttpMessageConverter 將輸入流轉換成對應的參數

基于Name 的 HandlerMethodArgumentResolver

這類參數解決器都基于抽象類 AbstractNamedValueMethodArgumentResolver 實現(xiàn)的, 在抽象類中定義了解決參數的主邏輯, 而子類只需要實現(xiàn)對應的模版方法即可以(PS: 這里蘊含了 策略與模版模式), 主邏輯如下:

public final Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
    // 創(chuàng)建 MethodParameter 對應的 NamedValueInfo
    NamedValueInfo namedValueInfo = getNamedValueInfo(parameter);
    MethodParameter nestedParameter = parameter.nestedIfOptional();     // Java 8 中支持的 java.util.Optional
    // 因為此時的 name 可能還是被 ${} 符號包裹, 則通過 BeanExpressionResolver 來進行解析
    Object resolvedName = resolveStringValue(namedValueInfo.name);
    if (resolvedName == null) throw new IllegalArgumentException("Specified name must not resolve to null: [" + namedValueInfo.name + "]");
    // 下面的數據大體通過 HttpServletRequest, Http Headers, URI template variables(URI 模版變量) 獲取
    // @PathVariable     --> 通過前期對 uri 解析后得到的 decodedUriVariables 獲得
    // @RequestParam     --> 通過 HttpServletRequest.getParameterValues(name) 獲取
    // @RequestAttribute --> 通過 HttpServletRequest.getAttribute(name) 獲取   <-- 這里的 scope 是 request
    // @RequestHeader    --> 通過 HttpServletRequest.getHeaderValues(name) 獲取
    // @CookieValue      --> 通過 HttpServletRequest.getCookies() 獲取
    // @SessionAttribute --> 通過 HttpServletRequest.getAttribute(name) 獲取 <-- 這里的 scope 是 session
    // 通過 resolvedName 來解決參數的真實數據  <-- 模版方法
    Object arg = resolveName(resolvedName.toString(), nestedParameter, webRequest);
    if (arg == null) {
        if (namedValueInfo.defaultValue != null) {
            // 若 arg == null, 則使用 defaultValue, 這里默認值可能也是通過占位符 ${...} 來進行查找
            arg = resolveStringValue(namedValueInfo.defaultValue);
        } else if (namedValueInfo.required && !nestedParameter.isOptional()) {
            // 若 arg == null && defaultValue == null && 非 optional 類型的參數 則通過 handleMissingValue 來進行處理, 一般是報異常
            handleMissingValue(namedValueInfo.name, nestedParameter, webRequest);
        }
        // 對 null 值的處理 一般還是報異常
        arg = handleNullValue(namedValueInfo.name, arg, nestedParameter.getNestedParameterType());
    } // 若得到的數據是 "", 則還是使用默認值
    else if ("".equals(arg) && namedValueInfo.defaultValue != null) {
        // 這里的默認值有可能也是 ${} 修飾的, 所以也需要通過 BeanExpressionResolver 來進行解析
        arg = resolveStringValue(namedValueInfo.defaultValue);
    }
    if (binderFactory != null) {
        WebDataBinder binder = binderFactory.createBinder(webRequest, null, namedValueInfo.name);
        try { // 通過 WebDataBinder 中的 Converter 將 arg 轉換成 parameter.getParameterType() 對應的類型
              // 將 arg 轉換成 parameter.getParameterType() 類型, 這里就需要 SimpleTypeConverter
            arg = binder.convertIfNecessary(arg, parameter.getParameterType(), parameter);
        } catch (ConversionNotSupportedException ex) {
            throw new MethodArgumentConversionNotSupportedException(arg, ex.getRequiredType(), namedValueInfo.name, parameter, ex.getCause());
        } catch (TypeMismatchException ex) {
            throw new MethodArgumentTypeMismatchException(arg, ex.getRequiredType(), namedValueInfo.name, parameter, ex.getCause());
        }
    }
    // 這里的 handleResolvedValue 一般是空實現(xiàn), 在PathVariableMethodArgumentResolver中也是存儲一下數據到 HttpServletRequest 中
    handleResolvedValue(arg, namedValueInfo.name, parameter, mavContainer, webRequest);
    return arg;
}

上面代碼的主要流程如下:

1. 基于 MethodParameter 構建 NameValueInfo <-- 主要有 name, defaultValue, required

2. 通過 BeanExpressionResolver(${}占位符解析器) 解析 name

3. 通過模版方法 resolveName 從 HttpServletRequest, Http Headers, URI template variables 中獲取對應的屬性值

4. 對 arg == null 這種情況的處理, 要么使用默認值, 若 required = true && arg == null, 則一般報出異常

5. 通過 WebDataBinder 將 arg 轉換成 Methodparameter.getParameterType() 類型

子類主要需要完成如下操作:

1. 根據 MethodParameter 創(chuàng)建 NameValueInfo
2. 根據 name 從 HttpServletRequest, Http Headers, URI template variables 獲取屬性值
3. 對 arg == null 這種情況的處理

主要子類

1. SessionAttributeMethodArgumentResolver
    針對 被 @SessionAttribute 修飾的參數起作用, 參數的獲取一般通過 HttpServletRequest.getAttribute(name, RequestAttributes.SCOPE_SESSION)
2. RequestParamMethodArgumentResolver
    針對被 @RequestParam 注解修飾, 但類型不是 Map, 或類型是 Map, 并且 @RequestParam 中指定 name, 一般通過 MultipartHttpServletRequest | HttpServletRequest 獲取數據
3. RequestHeaderMethodArgumentResolver
    針對 參數被 RequestHeader 注解, 并且 參數不是 Map 類型, 數據通過 HttpServletRequest.getHeaderValues(name) 獲取
4. RequestAttributeMethodArgumentResolver
    針對 被 @RequestAttribute 修飾的參數起作用, 參數的獲取一般通過 HttpServletRequest.getAttribute(name, RequestAttributes.SCOPE_REQUEST)
5. PathVariableMethodArgumentResolver
    解決被注解 @PathVariable 注釋的參數 <- 這個注解對應的是 uri 中的數據, 在解析 URI 中已經進行解析好了 <- 在 RequestMappingInfoHandlerMapping.handleMatch -> getPathMatcher().extractUriTemplateVariables
6. MatrixVariableMethodArgumentResolver
    針對被 @MatrixVariable 注解修飾的參數起作用,  從 HttpServletRequest 中獲取去除 ; 的 URI Template Variables 獲取數據
7. ExpressionValueMethodArgumentResolver
    針對被 @Value 修飾, 返回 ExpressionValueNamedValueInfo
8. ServletCookieValueMethodArgumentResolver
    針對被 @CookieValue 修飾, 通過 HttpServletRequest.getCookies 獲取對應數據

上面子類中, 最讓人困惑的可能是 PathVariableMethodArgumentResolver, 但是再結合 RequestMappingInfoHandlerMapping.handleMatch -> getPathMatcher().extractUriTemplateVariables 就發(fā)現(xiàn)原來數據的獲取在通過 HandlerMapping 獲取 handler 時就進行了處理!

解決類型是Map 的 HandlerMethodArgumentResolver

這個方法參數解析器需要結合上面的第一種參數解析器, 主要有如下的類型:

1. RequestParamMapMethodArgumentResolver
    針對被 @RequestParam注解修飾, 且參數類型是 Map 的, 且 @RequestParam 中沒有指定 name, 從 HttpServletRequest 里面獲取所有請求參數, 最后封裝成 LinkedHashMap|LinkedMultiValueMap 的參數解析器
2. RequestHeaderMapMethodArgumentResolver
    解決被 @RequestHeader 注解修飾, 并且類型是 Map 的參數, HandlerMethodArgumentResolver會將 Http header 中的所有 name <--> value 都放入其中
3. PathVariableMapMethodArgumentResolver
    針對被 @PathVariable 注解修飾, 并且類型是 Map的, 且 @PathVariable.value == null, 從 HttpServletRequest 中所有的 URI 模版變量 (PS: URI 模版變量的獲取是通過 RequestMappingInfoHandlerMapping.handleMatch 獲取)
4. MatrixVariableMapMethodArgumentResolver
    針對被 @MatrixVariable 注解修飾, 并且類型是 Map的, 且 MatrixVariable.name == null, 從 HttpServletRequest 中獲取 URI 模版變量 <-- 并且是去除 ;
5. MapMethodProcessor
    針對被 參數是 Map, 數據直接從 ModelAndViewContainer 獲取 Model

解決固定類型的 HandlerMethodArgumentResolver

主要的數據獲取還是通過 HttpServletRequest, HttpServletResponse

1. UriComponentsBuilderMethodArgumentResolver
    支持參數類型是 UriComponentsBuilder, 直接通過 ServletUriComponentsBuilder.fromServletMapping(request) 構建對象
2. SessionStatusMethodArgumentResolver
    支持參數類型是 SessionStatus, 直接通過 ModelAndViewContainer 獲取 SessionStatus
3. ServletResponseMethodArgumentResolver
    支持 ServletResponse, OutputStream, Writer 類型, 數據的獲取通過 HttpServletResponse
4. ServletRequestMethodArgumentResolver
    支持 WebRequest, ServletRequest, MultipartRequest, HttpSession, Principal, InputStream, Reader, HttpMethod, Locale, TimeZone, 數據通過 HttpServletRequest 獲取
5. RedirectAttributesMethodArgumentResolver
    針對 RedirectAttributes及其子類的參數 的參數解決器, 主要還是基于 NativeWebRequest && DataBinder (通過 dataBinder 構建 RedirectAttributesModelMap)
6. ModelMethodProcessor
    針對 Model 及其子類的參數, 數據的獲取一般通過 ModelAndViewContainer.getModel()

除了上面的幾個類, 還有一個特別的 HandlerMethodArgumentResolver, 它就是 ModelAttributeMethodProcessor, 主要是針對 被 @ModelAttribute 注解修飾且不是普通類型(通過 !BeanUtils.isSimpleProperty來判斷)的參數, 而參數的獲取通過 從 ModelAndViewContainer.ModelMap 中獲取數據值, 主邏輯如下:

public final Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
    // 獲取 @ModelAttribute 中指定 name
    String name = ModelFactory.getNameForParameter(parameter);
    // 從 ModelAndViewContainer.ModelMap 中獲取數據值 | 通過構造函數創(chuàng)建一個
    Object attribute = (mavContainer.containsAttribute(name) ? mavContainer.getModel().get(name) : createAttribute(name, parameter, binderFactory, webRequest));
    // 檢測 name 是否可以進行綁定
    if (!mavContainer.isBindingDisabled(name)) {
        ModelAttribute ann = parameter.getParameterAnnotation(ModelAttribute.class);
        if (ann != null && !ann.binding()) mavContainer.setBindingDisabled(name);
    }
    // 此處進行參數的綁定操作 (PS: 下面的 attribute 就是 DataBinder 的 target)
    WebDataBinder binder = binderFactory.createBinder(webRequest, attribute, name);
    if (binder.getTarget() != null) {
        if (!mavContainer.isBindingDisabled(name)) {  // 若可以進行參數的綁定
            bindRequestParameters(binder, webRequest); // 進行參數的綁定
        }
        // applicable: 合適 <-- 這里是進行參數的檢查
        validateIfApplicable(binder, parameter);
        // 檢查在校驗的過程中是否出錯
        if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) throw new BindException(binder.getBindingResult());
    }
    // 將 resolved 后的 Model 放入 ModelAndViewContainer 中
    // Add resolved attribute and BindingResult at the end of the model
    Map<String, Object> bindingResultModel = binder.getBindingResult().getModel();
    mavContainer.removeAttributes(bindingResultModel);
    mavContainer.addAllAttributes(bindingResultModel);
    // 通過 SimpleTypeConverter 進行參數的轉換
    return binder.convertIfNecessary(binder.getTarget(), parameter.getParameterType(), parameter);
}

基于 ContentType 利用 HttpMessageConverter 將輸入流轉換成對應的參數的 HandlerMethodArgumentResolver

這類參數解析器的基類是 AbstractMessageConverterMethodArgumentResolver, 如下是其主要的屬性

// 解決 HandlerMethod 中的 argument 時使用到的 HttpMessageConverters
protected final List<HttpMessageConverter<?>> messageConverters;
// 支持的 MediaType  <-- 通過這里的 MediaType 來篩選對應的 HttpMessageConverter
protected final List<MediaType> allSupportedMediaTypes;
// Request/Response 的 Advice <- 這里的 Advice 其實就是 AOP 中 Advice 的概念
// RequestAdvice 在從 request 中讀取數據之前|后
// ResponseAdvice 在 將數據寫入 Response 之后
private final RequestResponseBodyAdviceChain advice;

對應的主邏輯如下:

protected <T> Object readWithMessageConverters(HttpInputMessage inputMessage, MethodParameter parameter,
        Type targetType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {
    MediaType contentType;
    boolean noContentType = false;
    try { // 獲取 Http 請求頭中的 contentType
        contentType = inputMessage.getHeaders().getContentType();       
    } catch (InvalidMediaTypeException ex) {
        // 獲取失敗則報 HttpMediaTypeNotSupportedException, 根據 DefaultHandlerExceptionResolver, 則報出 Http.status = 415
        throw new HttpMediaTypeNotSupportedException(ex.getMessage());  
    }
    // 若 contentType == null, 則設置默認值, application/octet-stream
    if (contentType == null) {                                          
        noContentType = true;
        contentType = MediaType.APPLICATION_OCTET_STREAM;
    }
    // 獲取 方法的聲明類
    Class<?> contextClass = (parameter != null ? parameter.getContainingClass() : null);
    // 獲取請求參數的類型
    Class<T> targetClass = (targetType instanceof Class ? (Class<T>) targetType : null);                
    if (targetClass == null) {   // 若 targetClass 是 null, 則通過工具類 ResolvableType 進行解析                                                                        
        ResolvableType resolvableType = (parameter != null ? ResolvableType.forMethodParameter(parameter) : ResolvableType.forType(targetType));
        targetClass = (Class<T>) resolvableType.resolve();                                              // 獲取參數的類型
    }
    // 獲取請求的類型 HttpMethod (GET, POST, INPUT, DELETE 等)
    HttpMethod httpMethod = ((HttpRequest) inputMessage).getMethod();                                   
    Object body = NO_VALUE;
    try {
        inputMessage = new EmptyBodyCheckingHttpInputMessage(inputMessage);
        // 循環(huán)遍歷 HttpMessageConverter, 找出支持的 HttpMessageConverter
        for (HttpMessageConverter<?> converter : this.messageConverters) {                              
            Class<HttpMessageConverter<?>> converterType = (Class<HttpMessageConverter<?>>) converter.getClass();
            // 下面分成兩類 HttpMessageConverter 分別處理
            if (converter instanceof GenericHttpMessageConverter) {
                GenericHttpMessageConverter<?> genericConverter = (GenericHttpMessageConverter<?>) converter;
                // 判斷 GenericHttpMessageConverter 是否支持 targetType + contextClass + contextType 這些類型
                if (genericConverter.canRead(targetType, contextClass, contentType)) {
                    logger.info("Read [" + targetType + "] as \"" + contentType + "\" with [" + converter + "]");
                    if (inputMessage.getBody() != null) { // 若處理后有 request 值
                        // 在通過 GenericHttpMessageConverter 處理前 過一下 Request 的 Advice <-- 其實就是個切面
                        inputMessage = getAdvice().beforeBodyRead(inputMessage, parameter, targetType, converterType);
                        // 通過 GenericHttpMessageConverter 來處理請求的數據
                        body = genericConverter.read(targetType, contextClass, inputMessage);
                        // 在 GenericHttpMessageConverter 處理后在通過 Request 的 Advice 來做處理 <-- 其實就是個切面
                        body = getAdvice().afterBodyRead(body, inputMessage, parameter, targetType, converterType);
                    }
                    else { // 若處理后沒有值, 則通過 Advice 的 handleEmptyBody 方法來處理
                        body = getAdvice().handleEmptyBody(null, inputMessage, parameter, targetType, converterType);
                    }
                    break;
                }
            }
            else if (targetClass != null) {
                // 判斷 HttpMessageConverter 是否支持 這種類型的數據
                if (converter.canRead(targetClass, contentType)) {
                    logger.info("Read [" + targetType + "] as \"" + contentType + "\" with [" + converter + "]");
                    if (inputMessage.getBody() != null) { // 若處理后有 request 值
                        // 在通過 HttpMessageConverter 處理前 過一下 Request 的 Advice <-- 其實就是個切面
                        inputMessage = getAdvice().beforeBodyRead(inputMessage, parameter, targetType, converterType);
                        // 通過 HttpMessageConverter 來處理請求的數據
                        body = ((HttpMessageConverter<T>) converter).read(targetClass, inputMessage);
                        // 在 HttpMessageConverter 處理后在通過 Request 的 Advice 來做處理 <-- 其實就是個切面
                        body = getAdvice().afterBodyRead(body, inputMessage, parameter, targetType, converterType);
                    }
                    else { // 若 Http 請求的 body 是 空, 則直接通過 Request/ResponseAdvice 來進行處理
                        body = getAdvice().handleEmptyBody(null, inputMessage, parameter, targetType, converterType);
                    }
                    break;
                }
            }
        }
    } catch (IOException ex) {
        throw new HttpMessageNotReadableException("I/O error while reading input message", ex);
    }
    if (body == NO_VALUE) {  // 若 body 里面沒有數據, 則
        if (httpMethod == null || !SUPPORTED_METHODS.contains(httpMethod) || (noContentType && inputMessage.getBody() == null)) return null;
        // 不滿足以上條件, 則報出異常
        throw new HttpMediaTypeNotSupportedException(contentType, this.allSupportedMediaTypes);
    }
    return body;
}

對應流程如下:

1. 獲取 Http 請求的 contentType
2. 獲取請求參數的類型
3. 循環(huán)遍歷 HttpMessageConverter, 通過 canRead 判斷是否支持對應的參數類型解決
4. 循環(huán)遍歷 ApplicationContext 中的 RequestBodyAdvice, 若支持的話, 則通過 RequestBodyAdvice 在 對 HttpServletRequest 讀取的數據之前 進行一些增強操作
5. 通過 GenericHttpMessageConverter 來處理請求的數據
6. 在 GenericHttpMessageConverter 處理后在通過 Request 的 Advice 來做處理 <-- 其實就是個切面
7. 若請求的 body沒有數據, 則通過 Advice 的 handleEmptyBody 方法來處理

對應的子類具有如下:

1. RequestPartMethodArgumentResolver
    參數被 @RequestPart 修飾, 參數是 MultipartFile | javax.servlet.http.Part 類型, 數據通過 HttpServletRequest 獲取
2. HttpEntityMethodProcessor
    針對 HttpEntity|RequestEntity 類型的參數進行參數解決, 將 HttpServletRequest  里面的數據轉換成 HttpEntity|RequestEntity   <-- HandlerMethodArgumentResolver
3. RequestResponseBodyMethodProcessor
    解決被 @RequestBody 注釋的方法參數  <- 其間是用 HttpMessageConverter 進行參數的轉換 

上面 RequestResponseBodyMethodProcessor 是最常用得, 主要是針對 @RequestBody 注解, 并且其也是個 HandlerMethodReturnValueHandler(PS: 這個后面說), 其主流程如下:

public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
    // 獲取嵌套參數 <- 有可能參數是用 Optional
    parameter = parameter.nestedIfOptional();   
    // 通過 HttpMessageConverter 來將數據轉換成合適的類型
    Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
    // 獲取參數的名字
    String name = Conventions.getVariableNameForParameter(parameter);
    // 構建 WebDataBinder, 參數中的第二個值 arg 其實就是 DataBinder 的 target
    WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);  
    if (arg != null) {
        // @Validated 進行參數的校驗
        validateIfApplicable(binder, parameter);
        // 若有異常則直接暴出來
        if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
    }
    // 將綁定的結果保存在 ModelAndViewContainer 中
    mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
    // 對 Optional類型的參數的處理
    return adaptArgumentIfNecessary(arg, parameter);
}
@Override
protected <T> Object readWithMessageConverters(NativeWebRequest webRequest, MethodParameter parameter, Type paramType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {
    // 從 NativeWebRequest 中獲取  HttpServletRequest
    HttpServletRequest servletRequest = webRequest.getNativeRequest(HttpServletRequest.class);
    // 封裝 ServletServerHttpRequest
    ServletServerHttpRequest inputMessage = new ServletServerHttpRequest(servletRequest);
    // 通過 InputMessage 中讀取參數的內容, 并且 通過 HttpMessageConverter 來將數據轉換成 paramType 類型的參數
    Object arg = readWithMessageConverters(inputMessage, parameter, paramType);
    if (arg == null) {
        // 檢測參數是否是必需的
        if (checkRequired(parameter)) throw new HttpMessageNotReadableException("Required request body is missing: " + parameter.getMethod().toGenericString());
    }
    return arg; // 返回參數值
}

HandlerMethodArgumentResolver 中的優(yōu)秀設計

1. 策略模式: 主接口HandlerMethodArgumentResolver定義解決參數得方法, 根據不同得策略實現(xiàn)對應的子類
2. 組合模式: 通過 HandlerMethodArgumentResolverComposite 將支持的HandlerMethodArgumentResolver放在 HandlerMethodArgumentResolverComposite中, 進行統(tǒng)一處理, 與之對應的有 Dubbo 中以 Delegate 為尾綴的類名(從字面我們知道起代理作用, 但其只代理一個類)
3. 模版模式: 在抽象類AbstractMessageConverterMethodArgumentResolver中 定義解析參數的主邏輯, 而子類 HttpEntityMethodProcessor|RequestResponseBodyMethodProcessor實現(xiàn)具體的邏輯 
4. 建造者模式: UriComponentsBuilder <-- 基于 URL 構建 UriComponents

總結

整個 HandlerMethodArgumentResolver 的架構體系是個典型的 策略+模版+組合的設計模式, 其中的最通用的是 RequestResponseBodyMethodProcessor, 其通過 @RequestBody來對請求的數據根據 contentType, 用 HttpMessageConverter 進行轉換!

以上就是SpringMVC4.3解析器HandlerMethodArgumentResolver接口源碼的詳細內容,更多關于SpringMVC HandlerMethodArgumentResolver的資料請關注腳本之家其它相關文章!

相關文章

  • java將一個目錄下的所有文件復制n次

    java將一個目錄下的所有文件復制n次

    這篇文章主要為大家詳細介紹了java將一個目錄下的所有文件復制n次,文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2019-08-08
  • 高吞吐、線程安全的LRU緩存詳解

    高吞吐、線程安全的LRU緩存詳解

    這篇文章主要介紹了高吞吐、線程安全的LRU緩存詳解,分享了相關代碼示例,小編覺得還是挺不錯的,具有一定借鑒價值,需要的朋友可以參考下
    2018-02-02
  • Java實現(xiàn)數獨小游戲

    Java實現(xiàn)數獨小游戲

    這篇文章主要為大家詳細介紹了Java實現(xiàn)數獨小游戲,文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2021-05-05
  • Java常用集合與原理解析

    Java常用集合與原理解析

    這篇文章主要介紹了Java常用集合與原理解析,本文通過實例代碼給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2022-03-03
  • Java中的泛型方法詳解及簡單實例

    Java中的泛型方法詳解及簡單實例

    這篇文章主要介紹了Java中的泛型方法詳細介紹的相關資料,需要的朋友可以參考下
    2016-12-12
  • Java壓縮解壓縮工具類

    Java壓縮解壓縮工具類

    這篇文章主要為大家詳細介紹了Java壓縮解壓縮工具類,如何壓縮單個文件,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2018-12-12
  • SpringBoot利用MDC機制過濾單次請求的所有日志

    SpringBoot利用MDC機制過濾單次請求的所有日志

    在服務出現(xiàn)故障時,我們經常需要獲取一次請求流程里的所有日志進行定位 ,如何將一次數據上報請求中包含的所有業(yè)務日志快速過濾出來,就是本文要介紹的,需要的朋友可以參考下
    2024-04-04
  • IDEA中JetBrains Mono字體的正確安裝姿勢

    IDEA中JetBrains Mono字體的正確安裝姿勢

    在 JetBrains Mono 的設計階段,它就充分考慮到了長時間工作可能導致的眼睛疲勞問題,比如字母的大小和形狀、空間量、自然等寬平衡、不必要的細節(jié)、連字、以及難以區(qū)分的符號等,從而最終設計出了這么一款字體
    2021-06-06
  • SpringBoot生成條形碼的方案詳解

    SpringBoot生成條形碼的方案詳解

    在Spring Boot, Spring Cloud 項目中整合ZXing庫來生成條形碼在特定行業(yè)也是一個常見需求,ZXing是google開源的一個功能強大的Java庫,專門用于二維碼/條形碼等的生成與解析,所以本文給大家介紹了SpringBoot生成條形碼的方案,需要的朋友可以參考下
    2024-08-08
  • SpringCloud實現(xiàn)Eureka服務注冊與發(fā)現(xiàn)

    SpringCloud實現(xiàn)Eureka服務注冊與發(fā)現(xiàn)

    這篇文章主要介紹了SpringCloud如何實現(xiàn)Eureka服務注冊與發(fā)現(xiàn),幫助大家更好的理解和學習使用SpringCloud,感興趣的朋友可以了解下
    2021-05-05

最新評論