Может кто-нибудь объяснить использование аннотации spring @ScopedProxy? Я думал, что это связано с сеансом beans, но я не совсем уверен, что.
В моем использовании областей я использовал сессионный охват beans без аннотации @ScopedProxy (или без доверенных прокси-серверов), поэтому я действительно уверен, как правильно его использовать.
Раздел 3.4.4.5 в документах spring объясняет это довольно хорошо:
(обратите внимание, что следующее определение "userPreferences" bean в его подлинности является неполным):
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
<bean id="userManager" class="com.foo.UserManager">
<property name="userPreferences" ref="userPreferences"/>
</bean>
Из приведенной выше конфигурации видно, что singleton bean 'userManager' вводится ссылкой на пользовательские значения bean 'в пользовательском приложении с поддержкой сеанса HTTP. Главным моментом здесь является то, что "userManager" bean является одиночным... он будет создаваться точно один раз за контейнер, и его зависимостями strong > (в этом случае только один, "userPreferences" bean) также будет вводиться только один раз!.
Это означает, что "userManager" будет (концептуально) работать только с одним и тем же объектом "userPreferences" , то есть тем, с которым он был первоначально введен.
Это не то, что вы хотите, когда вы вводите bean с привязкой к сеансу HTTP как зависимость в сотрудничающий объект (обычно). Скорее, то, что мы хотим, это единственный объект userManager в контейнере, а затем для времени жизни сеанса HTTP, мы хотим видеть и использовать объект userPreferences, который специфичный для указанного сеанса HTTP.
Скорее всего, вам нужно ввести какой-то объект, который предоставляет тот же публичный интерфейс, что и класс UserPreferences (в идеале - объект, который является экземпляром UserPreferences), и который достаточно умен, чтобы можно было уйти и извлечь реального объекта UserPreferences из любого используемого нами механизма определения области видимости (HTTP-запрос, сеанс и т.д.). Затем мы можем безопасно ввести этот прокси-объект в "userManager" bean, который будет в блаженном неведении, что ссылка UserPreferences, на которую он держится, является прокси.
В нашем случае , когда экземпляр UserManager вызывает метод для объекта UserPreferences, вложенного с зависимостями, он действительно вызывает метод прокси-сервера... прокси-сервер затем отключится и выберет реальный объект UserPreferences из (в данном случае) сеанса HTTP и делегирование вызова метода на восстановленный реальный объект UserPreferences.
Вот почему вам нужна следующая, правильная и полная конфигурация при вводе объектов beans с запросом, сеансом и globalSession в сопутствующие объекты:
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session">
<aop:scoped-proxy/>
</bean>
<bean id="userManager" class="com.foo.UserManager">
<property name="userPreferences" ref="userPreferences"/>
</bean>