bahar kapsamlı vekil fasulye

Birisi bahar @ScopedProxyaçıklamasının kullanımını açıklayabilir mi? Ben düşündüm o seans kapsamlı fasulye ile ilgili bir şey vardı, ama tam emin neyi değilim.

Kapsam kullanımımda, @ScopedProxyaçıklama olmadan (veya aop kapsamlı proxy'ler olmadan) oturum kapsamlı fasulye kullandım , bu yüzden nasıl doğru şekilde kullanacağıma gerçekten eminim.

İlkbahar belgelerinin 3.4.4.5 Bölümü bunu oldukça iyi açıklıyor:

(Lütfen aşağıdaki 'userPreferences' fasulye tanımının eksik olduğuna dikkat edin):

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

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

Yukarıdaki konfigürasyondan, tekil bean "userManager" ın HTTP Oturum kapsamlı bean "userPreferences" referans alınarak enjekte edildiği açıktır. Burada önemli nokta olduğunu 'UserManager' fasulye bir tekil olduğu o olacak ... konteyner başına tam olarak bir kez örneği , ve bağımlılıkları (bu durumda sadece bir 'UserPreferences' fasulyesi olarak) Ayrıca sadece (bir kez enjekte edilecek! ) .

Bu, 'userManager'ın (kavramsal olarak) yalnızca aynı' userPreferences 'nesnesi, yani orijinal olarak enjekte edildiği nesne üzerinde çalışacağı anlamına gelir.

Bir ortak çalışma nesnesine (tipik olarak) bağımlılık olarak HTTP Oturumu kapsamlı bir fasulye enjekte ettiğinizde istediğiniz şey bu değildir. Daha ziyade, istediğimiz şey , konteyner başına tek bir 'userManager' nesnesidir ve daha sonra, bir HTTP Oturumunun ömrü boyunca, söz konusu HTTP Oturumuna özgü bir 'userPreferences' nesnesini görmek ve kullanmak istiyoruz .

Daha sonra ihtiyacınız olan şey, UserPreferences sınıfıyla (ideal olarak bir UserPreferences örneği olan bir nesne) tam olarak aynı ortak arabirimi ortaya çıkaran ve çıkıp gerçek UserPreferences nesnesini getirebilecek kadar akıllı olan bir tür nesne enjekte etmektir. seçtiğimiz temel kapsam belirleme mekanizmasından (HTTP isteği, Oturum, vb.). Daha sonra bu proxy nesnesini 'userManager' çekirdeğine güvenli bir şekilde enjekte edebiliriz; bu, üzerinde tuttuğu UserPreferences referansının bir proxy olduğunun farkında olmayacaktır .

Bizim durumumuzda, bir UserManager örneği bağımlılık enjekte edilmiş UserPreferences nesnesinde bir yöntemi çağırdığında, gerçekten proxy üzerinde bir yöntemi çağıracaktır ... daha sonra proxy kapanır ve gerçek UserPreferences nesnesini (bu durumda) alır. HTTP Oturumu ve alınan gerçek UserPreferences nesnesine yöntem çağrısı için yetki verin.

Bu nedenle, istek, oturum ve globalSession kapsamlı fasulyeleri işbirliği yapılan nesnelere enjekte ederken aşağıdaki, doğru ve eksiksiz yapılandırmaya ihtiyacınız vardır:

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

Burada belirtilen çeşitli farklı seçenekleri ve yay belgelerini denedikten sonra, Spring MVC'nin, @Controller açıklamasını kullandığınızda ve web uygulamanızda böyle birden fazla denetleyicinizin olduğu yerlerde garip bir şekilde otomatik kablolama denetleyicisi olduğunu anladım. Ek açıklama @RestController (value = "UniqueControllerv1") olarak değiştirildi, sorun çözüldü.