Spring 2.5 управляемых сервлетов: как?

Question

Поправь меня, если что-то не так.

Как я понимаю, вся функциональность Spring, а именно DI, работает при получении бинов через

Spring Context, т.е. метод getBean ().

В противном случае, никто не может работать, даже если мой метод помечен @Transactional, и я буду

создайте класс-владелец с новым оператором, управление транзакциями не будет предоставлено.

Я использую Tomcat 6 в качестве контейнера сервлета.

Итак, мой вопрос: как сделать методы Servlet управляемыми средой Spring.

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

базовые сервлеты Java, поэтому у них больше методов. Тем не менее, web.xml присутствует в приложении как обычно.

Дело в том, что я не контролирую поток создания сервлетов, я могу переопределить только несколько методов

каждого сервлета, поток в основном записан в некотором XML-файле, но я контролирую этот процесс

с использованием графического интерфейса.

Так что, в основном, я только добавляю код к нескольким методам каждого сервлета.

Как заставить эти методы управляться средой Spring? Основное, что мне нужно сделать, это

делает эти методы транзакционными (@Transactional).

комментарий к Божо: @ Божо Давай посмотрим.
В методах этих сервлетов я работаю с возможностями фреймворка, скажем, специальными переменными, которые получены и сохранены в текущем сеансе.
И что необходимо, так это циклически проходить по этим коллекциям на основе фреймворка, сохраняя при этом некоторые значения в базе данных.
То, что вы предлагаете, представляет новый очень сложный объект, чтобы его можно было передать на уровень обслуживания. (Сервисный уровень не будет ничего знать о фреймворке, его классах и объектах, хранящихся в текущем сеансе!
Во-первых, мы «оборачиваем» коллекции, основанные на фреймворке, в такой объект, поэтому копируем в него все. Опять же, метод уровня сервиса должен либо сохранить изменения в базе данных, либо, в худшем случае, вернуть новый сложный объект, чтобы метод инфраструктуры сервлета мог обновлять переменные структуры в зависимости от результата выполнения метода уровня сервиса.
Это обходной путь, но Как вы думаете, это хорошая идея?

Answer 1

Вы также можете определить свои сервлеты непосредственно в контексте приложения Spring. Вам потребуется сервлет «прокси», зарегистрированный в web.xml и делегирующий экземпляру сервлета, который настроен как bean-компонент в applicationContext.xml. Прокси-сервлет настроен с именем целевого компонента сервлета, он обнаруживает этот компонент с помощью WebApplicationContextUtils.getRequiredWebApplicationContext().getBean(...) и делегирует всю обработку целевому сервлету. В этом случае Spring полностью управляет экземпляром вашего сервлета.

Answer 2

Я бы посоветовал реструктурировать ваш код - делать транзакционные методы сервлетов не очень хорошая вещь. Поместите транзакционную логику в отдельный класс обслуживания и либо

• получить эти классы с пружинным управлением WebApplicationContextUtils.getRequiredWebApplicationContext().getBean(..) или
• в вашем методе сервлета init() получите ApplicationContext с помощью вышеуказанного метода и вызовите appCtx.getAutowireCapableBeanFactory().autowireBean(this). Таким образом, вы можете внедрить транзакционные классы в свой сервлет, как если бы он был подпружиненным.

Теперь вы можете делать все это, но это определенно не красивый путь. Я бы предложил использовать Spring MVC или любую другую инфраструктуру MVC (которая поддерживает интеграцию Spring его компонентов)

Если это все невозможно, в качестве последнего средства я думаю, что вы можете использовать @Configurable (на ваших сервлетах) с <context:load-time-weaver/>.

Answer 3

Посмотрите, как Spring прокси фильтрует: http://grepcode.com/file/repository.springsource.com/org.springframework/org.springframework.web/3.0.2/org/springframework/web/filter/DelegatingFilterProxy.java

Теоретически вы можете легко создать такой же тип прокси для сервлетов, а DispatcherServlet - своего рода прокси.