Org.springframework.web.context.request.RequestContextListener effect

In Spring2.0, in addition to the previous singleton and prototype added three new web scopes, respectively, the request, session and global session, Please refer to the relevant section of the spring official manual for their meanings and usage. If you want a bean in your container to have one of these new web scopes, in addition to configuring the appropriate scope property at the bean level, you must also make an additional initialization configuration at the container level. That is, add the following contextlistener to the Web application's XML declaration file, website:

1 <web-app>
2
3 <listener>
4 <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
5 </listener>
6
7 </web-app>

\

What is the use of class "Org.springframework.web.context.request.RequestContextListener"?
<!--load Spring Applicationcontex T--
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!--support the spring bean of Session scope--
<listener>
<listener-class>
Org.springframework.web.context.request.RequestContextListener
</listener-class>
</listener>

First, the configuration method
In Spring2.0, in addition to the previous singleton and prototype added three new web scopes, respectively, the request, session and global session, If you want a bean in your container to have one of these new web scopes, in addition to configuring the appropriate scope property at the bean level, you must also make an additional initialization configuration at the container level.

Java Code <web-app> <listener> <listener-class>org.springframework.web.context . Request. Requestcontextlistener</listener-class> </listener> </web-app>

<web-app>

<listener>

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

</listener>

</web-app>

If you are using an earlier version of the Web container (Servlet 2.4 ago), then you need to use a javax.servlet.Filter implementation.

Java code <web-app> ... <filter> <FILTER-NAME>REQUESTCONTEXTFILTER</FILTER-NAME&G            T        <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class> </filter> <filter-mapping> <filter-name>requestContextFilter</filter-name> <url-pattern& Gt;/*</url-pattern> </filter-mapping> ... </web-app>

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

There are two ways to do exactly the same thing: Bind an HTTP request object to a thread that serves the request based on Localthread. This allows the bean with the request and session scope to be accessed in the subsequent call chain.

Request Scope
<bean id= "loginaction" class= "com.foo.LoginAction" scope= "Request"/>


For each HTTP request, the spring container creates a completely new instance of the Loginaction bean based on the loginaction bean definition, and the loginaction bean instance is only valid within the current HTTP request. As a result, you can safely change the internal state of the built instance as needed, and other requests that are created from an instance of the Loginaction bean definition will not see these state changes specific to a request. When the processing request ends, the bean instance of the request scope is destroyed.

Session scope
<bean id= "userpreferences" class= "Com.foo.UserPreferences" scope= "Session"/>
For an HTTP session,spring container, an entirely new instance of the Userpreferences Bean is created based on the userpreferences bean definition, and the userpreferences Bean is only present in the current HTTP Session is valid. As with the request scope, you can safely change the internal state of the created instance as needed, while other HTTP sessions will not see the state changes that are specific to an HTTP session based on the instances created by Userpreferences. When the HTTP session is eventually discarded, the beans inside the HTTP session scope are discarded.

Global Session Scope

<bean id= "userpreferences" class= "com.foo.UserPreferences" scope= "Globalsession"/>

The global session scope is similar to the standard HTTP session scope, but it only makes sense in portlet-based Web applications. The Portlet specification defines the concept of a global session, which is shared by all the various portlets that make up a portlet Web application. The bean defined in the global session scope is limited to the lifetime of the world Portlet session.

Note that if you are writing a standard servlet-based Web application and you have defined one or more beans with the global session scope, the system will use the standard HTTP session scope and will not cause any errors
Second, why the need for additional configuration Requestcontextfilter
There may be a doubt that the Web container has been integrated with the spring container through Contextloaderlistener (or Contextloaderservlet), Why is there an additional requestcontextlistener to support the other 3 scopes of the bean, because Contextloaderlistener implements the Servletcontextlistener listener interface, The Servletcontextlistener is only responsible for monitoring the startup and shutdown events of the Web container. The Requestcontextfilter implements the Servletrequestlistener listener interface, which listens for HTTP request events and notifies the listener every time a request is received by the Web server. The Requestcontextfilter,spring container is more closely combined with the Web container by configuring it.
Three, scope dependence problem
If you inject a web-related scope bean into a singleton or prototype bean, in this case, you need spring AOP

Java code <bean name= "Car" class= "Com.demo.Car" scope= "request" > <aop:scoped-proxy/> </bean> <bean id= "Boss" class= "Com.demo.Boss" > <properrty name= "Car" ref= "car"/> </bean>