java

스프링 문서의 섹션 3.4.4.5 는이를 매우 잘 설명합니다.

(다음의 ‘userPreferences’bean 정의는 불완전합니다.)

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>

<bean id="userManager" class="com.foo.UserManager">
    <property name="userPreferences" ref="userPreferences"/>
</bean>

위의 구성에서 싱글 톤 빈 ‘userManager’가 HTTP 세션 범위 빈 ‘userPreferences’에 대한 참조와 함께 주입되고 있음이 분명합니다. 여기서 눈에 띄는 점은 ‘userManager’빈이 싱글 톤 이라는 것입니다 … 그것은 컨테이너 당 정확히 한 번 인스턴스화 되며 , 그 종속성 (이 경우에는 ‘userPreferences’빈) 도 주입됩니다 (한 번! ) .

이것은 ‘userManager’가 (개념적으로) 원래 주입 된 것과 똑같은 ‘userPreferences’객체에서만 작동한다는 것을 의미합니다.

이것은 HTTP 세션 범위 빈을 협업 객체 (일반적으로)에 종속성으로 삽입 할 때 원하는 것이 아닙니다. 오히려 우리가 원하는 것은 컨테이너 당 하나의 ‘userManager’객체이고 , HTTP Session의 수명 동안 우리는 HTTP Session에 특정한 ‘userPreferences’객체를보고 사용하려고합니다 .

오히려 필요한 것은 UserPreferences 클래스 (이상적으로는 UserPreferences 인스턴스 인 객체)와 똑같은 공용 인터페이스를 노출하고 실제 UserPreferences 객체를 가져올 수있을만큼 똑똑한 일종의 객체를 주입하는 것입니다. 우리가 선택한 기본 범위 지정 메커니즘 (HTTP 요청, 세션 등)에서. 그런 다음이 프록시 객체를 ‘userManager’빈에 안전하게 삽입 할 수 있습니다.이 빈은 UserPreferences 참조가 프록시 라는 것을 알지 못합니다 .

우리의 경우 UserManager 인스턴스가 종속성이 주입 된 UserPreferences 객체에 대한 메서드를 호출 할 때 실제로 프록시에서 메서드를 호출합니다 . 그러면 프록시가 꺼져서 실제 UserPreferences 객체를 가져옵니다 (이 경우). HTTP 세션을 호출하고 검색된 실제 UserPreferences 개체에 메서드 호출을 위임합니다.

이것이 요청, 세션 및 globalSession 범위의 Bean을 협업 객체에 삽입 할 때 다음과 같은 정확하고 완전한 구성이 필요한 이유입니다.

<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>

답변