Spring Web MVC 3.1.1 вызов преобразователя аргумента перед перехватчиком

Question

Я настраиваю свое приложение Spring MVC 3.1.1, как показано ниже. Ведение журнала показывает, что MyArgumentResolver.resolveArgument вызывается перед «MyInterceptor.preHandle». При использовании обоих в старой конфигурации (с явно заданным компонентом AnnotationMethodHandlerAdapter и т. Д.) Они вызываются наоборот. Я прочитал, что как-то критично, так как его конфигурация не дополняет другие параметры пространства имен mvc :. Я сталкиваюсь с той же проблемой?

<mvc:annotation-driven>
  <mvc:message-converters>
   ...
  </mvc:message-converters>     
  <mvc:argument-resolvers>
    <bean class="[...].MyArgumentResolver"/>
  </mvc:argument-resolvers>    
</mvc:annotation-driven>
<mvc:interceptors>
  <mvc:interceptor>       
    <mvc:mapping path="/home/**" />
    <bean class="[...].MyInterceptor" />
  </mvc:interceptor>
</mvc:interceptors>

Большое спасибо!

Answer 1

пружина 3.1 сиспользует другой набор классов для обработки запросов - например, AnnotationMethodHandlerAdapter заменяется на RequestMappingHandlerAdapter.Вы можете прочитать больше об этом здесь: http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/mvc.html#mvc-ann-requestmapping-31-vs-30

Для правильной работы с этими классами они добавили новый HandlerMethodArgumentResolver , который заменяет старый WebArgumentResolver интерфейс.Тем не менее, я считаю, что Spring автоматически попытается «обновить» старые WebArgumentResolvers, поместив их в AbstractWebArgumentResolverHandlerAdapter , такое поведение я наблюдал в процессе обновления.JavaDoc для AbstractWebArgumentResolverHandlerAdapter сообщает:

Примечание. Этот класс предназначен для обратной совместимости.Однако рекомендуется переписать WebArgumentResolver как HandlerMethodArgumentResolver.Поскольку supportParameter (org.springframework.core.MethodParameter) может быть реализован только путем фактического разрешения значения и проверки того, что результат не является WebArgumentResolver # UNRESOLVED ...

После выполнения кода, я думаю,то, что может происходить в вашем случае, это то, что новые классы вызывают функцию supportParameter перед выполнением preHandle в перехватчиках, но реализация AbstractWebArgumentResolverHandlerAdapter фактически вызывает метод resolArgument и проверяет UNRESOLVED в качестве возвращаемого типа, чтобы определить,распознаватель аргументов поддерживает данный аргумент, который будет выглядеть как вызываемый не по порядку.

Я подозреваю, что если вы перепишите свой преобразователь аргументов для реализации нового интерфейса HandlerMethodArgumentResolver, это решит вашу проблему.