Как реализовано @RequestMapping для поддержки гибких подписи

Question

Как мы уже знаем, метод обработчика, аннотированный @RequestMapping10, имеет возможность иметь очень гибкие подписи и в произвольном порядке. Таким образом, мы можем иметь такие методы, как в следующем в контроллере

@RequestMapping(value = "/helloworld") 
public String helloworld(){ 
    ... 
} 

или

@RequestMapping(value = "/helloworld") 
public String helloworld(HttpServletResponse response, HttpServletRequest request){ 
    ... 
} 

или

@RequestMapping(value = "/helloworld") 
public String helloworld(HttpServletRequest request, HttpServletResponse response){ 
    ... 
} 

Spring всегда можно найти правильный метод для вызова и передавать правильные параметры. Я хотел бы знать, что происходит за сценой, может кто-нибудь объяснить мне? Заранее спасибо.

Answer 1

При запуске весна использует отражение для сканирования через ваши методы @Controller для тех, которые были аннотированы @RequestMapping. Он регистрирует соответствующие экземпляры Method. Он создает внутреннюю структуру данных в стиле карты, так что он может соответствовать URL-адресу запроса с помощью метода обработчика.

Параллельно он строит List (из них) HandlerMethodArgumentResolver экземпляров. Это объекты стратегии. Весна имеет реализацию для каждого supported parameter type.

Как только у него есть метод обработчика, он получает все его типы параметров. Он перебирает список из HandlerMethodArgumentResolver s, проверяя, поддерживает ли текущий тип HandlerMethodArgumentResolver тип параметра. Если это так, он использует его для разрешения значения, которое будет использоваться в качестве аргумента. Если это не так, оно переходит к следующему. Если никто не может этого сделать, Spring выдает исключение. Он собирает все эти значения. Весна наконец вызывает invoke на объекте Method с собранными значениями аргументов в порядке.

Answer 2

это довольно простой механизм. в первую очередь методы перечислены с использованием рефлексии. то каждый метод с этой аннотацией (весна использует много разных аннотаций) обрабатывается каким-то контроллером контроллера. и снова с использованием отражающей пружины проверяет каждый параметр один за другим. если параметр имеет тип, определенный в некоторой карте или коллекции, объект этого типа выбирается из контекста весны и помещается в упорядоченный набор параметров. когда весна просматривает все параметры и находит все объекты для прохождения к этому методу, он выполняет этот метод с подготовленными параметрами - снова путем отражения.

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