Доступ к bean-объекту в области запросов в HandlerIntercaptor
Я очень новичок в Spring и веб-разработке в целом, поэтому, пожалуйста, потерпите меня, если вопрос кажется запутанным или неполным...
В настоящее время я работаю над проектом Spring, в котором есть компонент, который я назову re questContext, который содержит некоторые часто используемые данные. Этот bean-объект ограничен запросом и, по-видимому, заполняется фильтром сервлетов (дочерним элементом GenericFilterBean).
Я пытаюсь получить доступ к информации, содержащейся в этом компоненте, из другого компонента (я назову UserBean) в методе preHandle объекта HandlerInterceptor. В UserBean я использую @AutoWired для доступа к bean-компоненту, как показано ниже:
@Autowired
private RequestContext requestContext;
Затем в одном из методов UserBeans я пытаюсь получить доступ к необходимым данным. Проблема в том, что контекст запроса содержит все нулевые значения. Я подумал, что может быть какая-то проблема жизненного цикла, поскольку он не знаком с фильтрами, но, используя некоторые точки останова, я вижу, что фильтр выполняется до handlerInterceptor, и я вижу, как устанавливаются данные контекста запроса. В таком случае я ожидаю, что, по крайней мере, смогу получить к нему доступ в методе preHandle перехватчика, если не в других.
Остальная часть приложения (включая фильтр, перехватчик обработчика) - это весь существующий / известный рабочий код, поэтому я не думаю, что у меня возникли какие-либо проблемы с настройкой вплоть до того момента, когда я пытаюсь использовать этот компонент. Есть какая-то проблема либо с моими ожиданиями, либо с тем, как я пытаюсь получить к ним доступ.
ОБНОВЛЕНИЕ: я нашел один пример класса, который фактически использует re questContext. Это еще один фильтр (но реализующий фильтр напрямую по сравнению с расширением GenericFilterBean). Этот фильтр вызывает
SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext(this)
в его методе init(). Я заметил, что если я сделаю этот вызов непосредственно перед попыткой доступа к re questContext, то он будет создан с ожидаемыми значениями (также обратите внимание, что если я делаю это в конструкторе по умолчанию, он не работает). Что-то подсказывает мне, что в моем случае это не решение проблем с правами, но, надеюсь, это проливает некоторый свет на проблему.
Попытка прочитать о SpringBeanAutowiringSupport, чтобы лучше понять. Я думаю, что если я правильно понимаю, это указывает на то, что мой бин в настоящее время не имеет доступа к WebApplicationContext, поэтому автопроводка не работает по умолчанию до тех пор, пока не будет выполнен этот вызов (как только вызов сделан, последующие запросы, кажется, не требовать этого). Означает ли это какую-то проблему с тем, как я настроил bean-компонент (он не зарегистрирован в IoC правильно?) Aagain, пожалуйста, прости меня за недостаток знаний весной, я до сих пор не знаю так много об этом, как IoC...
1 ответ
Ну, похоже, что ElderMael был на что-то, и мой вопрос в конечном итоге отвечает на этот вопрос: Как создаются экземпляры Spring HandlerInterceptors?
В отсутствие определения области для перехватчика и используемых им компонентов, они являются синглетонами и создаются с одним экземпляром requestContext. Когда для каждого запроса создаются последующие экземпляры, у меня остается старый исходный экземпляр. Я полагаю, что добавление метода processInjectionBasedOnCurrentContext - это просто повторная обработка автопроводки и поиск вновь созданного экземпляра. Мне придется подумать об идеальном способе решения этой проблемы, но я думаю, что, поскольку у HandlerInterceptor нет необходимости сохранять состояние, я, вероятно, мог бы сделать это, а также связанные с запросами bean-объекты.