Доступ к ServletRequest несколько раз, последовательность выполнения
Фильтры и перехватчики - важная часть остальных приложений, я уже рассказывал о них обоих и сравнивал их в своей предыдущей статье, пожалуйста, ознакомьтесь с ними.
Как реализовать фильтры?
Реализация Servlet Filter действительно проста, мы реализуем javax.servlet.Filter, @Order указывает порядок, в котором фильтры должны выполняться. Мы указали порядок как 1, поэтому это будет первый фильтр, который будет выполнен. chain.doFilter, вызываемый в строке 18, передает объект запроса и ответа следующему фильтру в цепочке или обработчику, если это последний фильтр.
Внутри метода doFilter я проверил, могу ли я получить доступ к IP-адресу пользователя, параметрам запроса из запроса, полезных данных, т. Е. К телу запроса из объект запроса. Но проблема, с которой мы сталкиваемся, заключается в том, что запрос может быть прочитан только один раз, и если мы попытаемся получить к нему доступ в фильтре, он выдаст ошибку при обращении к нему в контроллере. Поэтому, чтобы этого не произошло, я создал оболочку, которая расширяет HttpServletRequestWrapper, чтобы возвращать копию запроса через его конструктор.
Теперь, когда мы можем обращаться к объекту запроса несколько раз, я создал класс для возврата параметров из объекта запроса, который я использовал как в Servlet Filter, так и в Handler Interceptor для демонстрационных целей.
Итак, в TransactionFilter я автоматически подключил этот класс и передал завернутый объект Request в каждую из функций и распечатал возвращаемые из них значения.
Как реализовать обработчик-перехватчик?
Interceptor очень похож на фильтр, его просто нужно добавить в InterceptorRegistry.
Interceptor реализует интерфейс HandlerInterceptor, который имеет 3 основных метода:
- prehandle () - вызывается перед выполнением фактического обработчика, но представление еще не создано
- postHandle () - вызывается после выполнения обработчика
- afterCompletion () - вызывается после завершения полного запроса и создания представления
Я распечатал элементы из объекта запроса так же, как и в случае с фильтром. Теперь, когда перехватчик готов, нам нужно зарегистрироваться в InterceptorRegistry.
Теперь, когда мы закончили кодирование наших фильтров и перехватчиков, давайте посмотрим на иерархию, в которой эти методы перехватывают остальные вызовы api. Я создал контроллер, чтобы добавить ученика и получить ученика по идентификатору, давайте позвоним через почтальона и посмотрим, как работают фильтр и перехватчик.
Если мы видим последовательность операторов печати, HTTP-запрос сначала попадает в фильтр сервлета, где печатается IP-адрес пользователя и полезная нагрузка, поскольку в запросе нет параметров запроса, это не так. Печатаю. Затем запрос достиг метода предварительной обработки в перехватчике обработчика, где он печатает те же данные, а затем он достигает фактического контроллера, где объект ученика сохраняется в базе данных.
Итак, порядок идет от 1. Фильтр » 2. Перехватчик «➡️ 3. Контроллер для HTTP-запроса.
От контроллера ответ сначала переходит в метод обработки сообщений, а затем в метод после завершения. в перехватчике. Давайте также проверим пример для requestparams.
Последовательность такая же, как и раньше, с той лишь разницей, что мы не видим полезную нагрузку из тела запроса, поскольку это запрос на получение, а идентификатор, который был отправлен в параметрах запроса, виден.
Вы можете просмотреть код в моем репозитории на GitHub, я брошу ссылку ниже. Если вы найдете эту статью полезной, пожалуйста, отпустите несколько аплодисментов и не стесняйтесь поделиться.
Это раздача Винеша. Пока
