一、配置方式 
在Spring2.0中除了以前的Singleton和Prototype外又加入了三个新的web作用域，分别为request、session和global session，如果你想让你的容器里的某个bean拥有其中某种新的web作用域，除了在bean级上配置相应的scope属性，还必须在容器级做一个额外的初始化配置。 
Java代码   收藏代码
  1. <web-app>  
  2.   
  3.       <listener>  
  4.             <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>  
  5.       </listener>  
  6.   
  7. </web-app>  

如果你用的是早期版本的web容器（Servlet 2.4以前），那么你要使用一个javax.servlet.Filter的实现。 
Java代码   收藏代码
  1. <web-app>  
  2. ...  
  3.     <filter>  
  4.         <filter-name>requestContextFilter</filter-name>  
  5.         <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>  
  6.     </filter>  
  7.     <filter-mapping>  
  8.         <filter-name>requestContextFilter</filter-name>  
  9.         <url-pattern>/*</url-pattern>  
  10.     </filter-mapping>  
  11. ...  
  12. </web-app>  

两种方式完成完全一样的功能：基于LocalThread将HTTP request对象绑定到为该请求提供服务的线程上。这使得具有request和session作用域的bean能够在后面的调用链中被访问到。 

Request作用域 
<bean id="loginAction" class="com.foo.LoginAction" scope="request"/> 


针对每次HTTP请求，Spring容器会根据loginAction bean定义创建一个全新的LoginAction bean实例，且该loginAction bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态，而其他请求中根据loginAction bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。当处理请求结束，request作用域的bean实例将被销毁。 

Session作用域 
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/> 
针对某个HTTP Session，Spring容器会根据userPreferences bean定义创建一个全新的userPreferences bean实例，且该userPreferences bean仅在当前HTTP Session内有效。与request作用域一样，你可以根据需要放心的更改所创建实例的内部状态，而别的HTTP Session中根据userPreferences创建的实例，将不会看到这些特定于某个HTTP Session的状态变化。当HTTP Session最终被废弃的时候，在该HTTP Session作用域内的bean也会被废弃掉。 

global session作用域 

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

global session作用域类似于标准的HTTP Session作用域，不过它仅仅在基于portlet的web应用中才有意义。Portlet规范定义了全局Session的概念，它被所有构成某个portlet web应用的各种不同的portlet所共享。在global session作用域中定义的bean被限定于全局portlet Session的生命周期范围内。 

请注意，假如你在编写一个标准的基于Servlet的web应用，并且定义了一个或多个具有global session作用域的bean，系统会使用标准的HTTP Session作用域，并且不会引起任何错误 
二、为什么需要额外的配置RequestContextFilter 
也许会有一个疑问，已经通过ContextLoaderListener(或ContextLoaderServlet)将Web容器与Spring容器整合，为什么这里还要用额外的RequestContextListener以支持Bean的另外3个作用域，原因是ContextLoaderListener实现ServletContextListener监听器接口，而ServletContextListener只负责监听Web容器的启动和关闭的事件。RequestContextFilter实现ServletRequestListener监听器接口，该监听器监听HTTP请求事件，Web服务器接收的每次请求都会通知该监听器。通过配置RequestContextFilter，Spring容器与Web容器结合的更加密切。 
三、作用域依赖问题 

如果将Web相关作用域的Bean注入到singleton或prototype的Bean中，这种情况下，需要Spring AOP 

Java代码   收藏代码
  1. <bean name="car" class="com.demo.Car" scope="request">  
  2.     <aop:scoped-proxy/>  
  3. </bean>  
  4. <bean id="boss" class="com.demo.Boss" >  
  5.     <properrty name="car" ref="car" />  
  6. </bean>  

Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生