Section 3.4.4.5 of the spring docs explains it pretty well:
(please note that the following ‘userPreferences’ bean definition as it stands is incomplete):
<!-- an HTTP Session-scoped bean -->
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
<!-- a singleton-scoped bean -->
<bean id="userManager" class="com.foo.UserManager">
<property name="userPreferences" ref="userPreferences"/>
</bean>
From the above configuration it is evident that the singleton bean ‘userManager’ is being injected with a reference to the HTTP Session-scoped bean ‘userPreferences’. The salient point here is that the ‘userManager’ bean is a singleton… it will be instantiated exactly once per container, and its dependencies (in this case only one, the ‘userPreferences’ bean) will also only be injected (once!).
This means that the ‘userManager’ will (conceptually) only ever operate on the exact same ‘userPreferences’ object, that is the one that it was originally injected with.
This is not what you want when you inject a HTTP Session-scoped bean as a dependency into a collaborating object (typically). Rather, what we do want is a single ‘userManager’ object per container, and then, for the lifetime of a HTTP Session, we want to see and use a ‘userPreferences’ object that is specific to said HTTP Session.
Rather what you need then is to inject some sort of object that exposes the exact same public interface as the UserPreferences class (ideally an object that is a UserPreferences instance) and that is smart enough to be able to go off and fetch the real UserPreferences object from whatever underlying scoping mechanism we have chosen (HTTP request, Session, etc.). We can then safely inject this proxy object into the ‘userManager’ bean, which will be blissfully unaware that the UserPreferences reference that it is holding onto is a proxy.
In our case, when a UserManager instance invokes a method on the dependency-injected UserPreferences object, it will really be invoking a method on the proxy… the proxy will then go off and fetch the real UserPreferences object from (in this case) the HTTP Session, and delegate the method invocation onto the retrieved real UserPreferences object.
That is why you need the following, correct and complete, configuration when injecting request-, session-, and globalSession-scoped beans into collaborating objects:
<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>