Springда Request, Session, Application, ва WebSocketнинг кўринишлари

request, session, application ва websocket кўринишлари фақат вебни қўллаб-қувватлаш билан Spring фреймворкида ApplicationContextни амалга оширишда (XmlWebApplicationContext каби) мавжуд. Агар сиз ушбу кўринишларни Spring'нинг оддий IoC-контейнерлари билан ишлатсангиз, масалан ClassPathXmlApplicationContext, белгисиз кўриниш хатоси билан IllegalStateException яратилади.

Бошланғич веб конфигурация

request, session, application ва websocket (вебни қамраб олган) кўриниш бошланишидан олдин бинни аниқлаш учун кичик бошланғич созлаш талаб этилади. (Бошланғич созлаш стандарт кўринишлар учун талаб қилинмайди: singleton ва prototype).

Бу бошланғич созлашни қандай амалга оширишингиз сиз танлаган сервер муҳитига боғлиқ.

Агар сиз Spring Web MVCда кўринишдаги бинларга мурожаат қилаётган бўлсангиз, яъни Spring DispatcherServlet томонидан ишлов берилган сўровлар чегарасида, ҳеч қандай махсус созлама талаб этилмайди. DispatcherServlet аллақачон тегишли ҳолатларни очиб берган.

Агар сиз Spring DispatcherServletдан ташқари ишлов бериладиган сўровлар билан Servlet 2.5 веб-контейнеридан фойдаланаётган бўлсангиз (масалан, JSF ёки Struts билан), сиз org.springframework.web.context.request.RequestContextListener ServletRequestListenerни рўйхатдан ўтказишингиз керак. Servlet 3.0+ учун буни программавий равишда WebApplicationInitializer интерфейсидан фойдаланиб амалга ошириш мумкин. Ёки бошқа йўли бўлмаса ёхуд эски контейнер версиялари учун, веб-дастурингиздаги web web.xml файлига қуйидаги эълонни қўшинг:

<web-app>
    ...
    <listener>
        <listener-class>
            org.springframework.web.context.request.RequestContextListener
        </listener-class>
    </listener>
    ...
</web-app>

Альтернатив равишда, агар тингловчи созланмасида муаммо бўлса, Springда RequestContextFilterдан фойдаланишни кўриб чиқинг. Фильтрнинг кўрсатилиши веб-дастур конфигурациясига боғлиқ, шунинг учун уни тегишли равишда ўзгартириш керак. Қуйидаги рўйхатда веб-дастур фильтр қисмининг қисқача баёни берилган:

<web-app>
    ...
    <filter>
        <filter-name>requestContextFilter</filter-name>
        <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>requestContextFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    ...
</web-app>

DispatcherServlet, RequestContextListener ва RequestContextFilter бир хил иш қилади, яъни HTTP сўров объектларини бу сўровга хизмат кўрсатиш учун Thread билан боғлайди. Бу сўров ёки session кўринишидаги бинларга занжир орқали кириш имконини беради.

Request кўриниши

Бинни аниқлаш учун қуйидаги XML-конфигурацияни кўrib чиқамиз:

<bean id="loginAction" class="com.something.LoginAction" scope="request"/>

Spring контейнер ҳар бир HTTP сўрови учун loginAction бин аниқлаш бўйича LoginAction бинининг янги экземпларини яратади. Бу ҳолда loginAction бин HTTP сўров даражасида кўринишда. Созилган экземпларнинг ички ҳолатини қанча хоҳласангиз ўзгартириш мумкин, чунки loginAction бин аниқловчи асосида яратилган бошқа экземплар бу ҳолат ўзгаришларини кўрмайди. Бу аниқ сўровга боғлиқ. Агар сўров ишлов беришни тугатса, бин сўров кўринишидан чиқарилади.

Агар аннотациялар билан бошқариладиган компонентлар ёки Java конфигурациялари фойдаланилса, @RequestScope аннотациясини request кўриниши компонентига тегишли қилиш учун ишлатиш мумкин. Қуйидаги мисолда бундай қилиш кўрсатилган:

@RequestScope
@Component
public class LoginAction {
    // ...
}

@RequestScope
@Component
class LoginAction {
    // ...
}

Session кўриниши

Бинни аниқлаш учун қуйидаги XML-конфигурацияни кўrib chiqамiz:

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

Spring контейнер userPreferences бин аниқловчи асосида бир HTTP Session давомида UserPreferences биннинг янги экземпларини яратади. Яъни, userPreferences бини HTTP Session даражасида кўринишда жойлашган. Request кўринишдаги бинлар каби, сиз яратилган экземпларнинг ички ҳолатини қанча хоҳласангиз ўзгартиришингиз мумкин, шунчаки бошқа HTTP Session экземплари ҳам бу ҳолат ўзгаришларини сезмайди, чунки улар алоҳида HTTP Sessionга тааллуқли. Агар HTTP Session тугаса, у аниқ HTTP Sessionга боғланган бин ҳам чиқарилади.

Агар аннотациялар билан бошқариладиган компонентлар ёки Java конфигурациялари фойдаланилса, @SessionScope аннотациясини session кўриниши компонентига тегишли қилиш учун ишлатиш мумкин.

@SessionScope
@Component
public class UserPreferences {
    // ...
}

@SessionScope
@Component
class UserPreferences {
    // ...
}

Application кўриниши

Бинни аниқлаш учун қуйидаги XML-конфигурацияни кўrib chiqamiz:

<bean id="appPreferences" class="com.something.AppPreferences" scope="application"/>

Spring контейнер appPreferences бин аниқловчи асосида бутун веб-дастур учун AppPreferences биннинг бир янги экземпларини яратади. Яъни, appPreferences бини ServletContext даражасида кўринишда жойлашган ва оддий ServletContext атрибути сифатида сақланади. У бутун Spring ApplicationContext учун эмас, фақат ҳар бир ServletContext учун объект-одиночка бўлиб, Spring ApplicationContextнинг бир қанча бўлмаганлиги ва атрибут сифатида мавжудлиги сабабли фарқли ҳисобланади.

Агар аннотациялар билан бошқариладиган компонентлар ёки Java конфигурациялари фойдаланилса, @ApplicationScope аннотациясини application кўриниши компонентига тегишли қилиш учун ишлатиш мумкин. Қуйидаги мисолда бундай қилиш кўрсатилган:

@ApplicationScope
@Component
public class AppPreferences {
    // ...
}

@ApplicationScope
@Component
class AppPreferences {
    // ...
}

WebSocket кўриниши

WebSocket кўриниши WebSocket сессияси ҳаёт цикли билан боғлиқ ва STOMP over WebSocket дастурларига тааллуқли.