Spring提供了两种方式用于初始化WebApplicationContext,ServletContext监听器、自启动Servlet。其中只有Servlet2.3以上版本的Web容器才支持ServletContext监听器方式初始化WebApplicationContext。
一、监听器方式(org.springframework.web.context.ContextLoaderListener)
1.ContextLoaderListener通过ServletContext上下文参数contextConfigLocation获取Spring配置文件的位置,在web.xml文件中Spring配置文件的位置,如下
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml,/WEB-INF/beanConfig.xml</param-value>
value可以用 -value> classpath:applicationContext.xml
</context-param>
在这里可以指定多个文件,多个文件之间用逗号或空格分割,也可以指定带资源类型前缀的路径配置,如“calsspath:/applicationContext.xml”、“classpath*:applicationContext*.xml”,对于未带资源类型前缀的路径配置默认其路径相对于Web部署的根路径。
classpath与classpath*的区别:假设有多个jar包或类路径下有一个相同的包名如(com.test),classpath只会在第一个加载的com.test包下查找,而classpath*会在所有jar包和类路径下查找。
2.在web.xml文件中配置监听器ContextLoaderListener,如下
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
<listener>
二、自启动Servlet方式(org.springframework.web.context.ContextLoaderServlet)
1.ContextLoaderServlet同样通过ServletContext上下文参数contextConfigLocation获取Spring配置文件的位置,配置跟一样。
2.配置自启动ContextLoaderServlet,如下
<servlet>
<servlet-name>springContextLoaderServlet</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
IntrospectorCleanupListener简介
spring中的提供了一个名为org.springframework.web.util.IntrospectorCleanupListener的监听器。它主要负责处理由 JavaBeans Introspector的使用而引起的缓冲泄露。spring中对它的描述如下:
它是一个在web应用关闭的时候,清除JavaBeans Introspector的监听器.在web.xml中注册这个listener.可以保证在web 应用关闭的时候释放与掉这个web 应用相关的class loader 和由它管理的类
如果你使用了JavaBeans Introspector来分析应用中的类,Introspector 缓冲中会保留这些类的引用.结果在你的应用关闭的时候,这些类以及web 应用相关的class loader没有被垃圾回收.
不幸的是,清除Introspector的唯一方式是刷新整个缓冲.这是因为我们没法判断哪些是属于你的应用的引用.所以删除被缓冲的introspection会导致把这台电脑上的所有应用的introspection都删掉.
需要注意的是,spring 托管的bean不需要使用这个监听器.因为spring它自己的introspection所使用的缓冲在分析完一个类之后会被马上从javaBeans Introspector缓冲中清除掉.
应用程序中的类从来不直接使用JavaBeans Introspector.所以他们一般不会导致内部查看资源泄露.但是一些类库和框架往往会产生这个问题.例如:Struts 和Quartz.
单个的内部查看泄漏会导致整个的web应用的类加载器不能进行垃圾回收.在web应用关闭之后,你会看到此应用的所有静态类资源(例如单例).这个错误当然不是由这个类自身引起的.
ContextLoaderListener简介
与BeanFactory通常以编程的方式被创建不同的是,ApplicationContext能以声明的方式创建,如使用ContextLoader。当然你也可以使用ApplicationContext的实现之一来以编程的方式创建ApplicationContext实例。首先,让我们先分析ContextLoader接口及其实现。
ContextLoader接口有两个实现:ContextLoaderListener和ContextLoaderServlet。两者都实现同样的功能,但不同的是,ContextLoaderListener不能在与Servlet 2.2兼容的web容器中使用。根据Servlet 2.4规范, servlet context listener要在web应用程序的servlet context建立后立即执行,并要能够响应第一个请求(在servlet context要关闭时也一样):这样一个servlet context listener是初始化Spring ApplicationContext的理想场所。虽然使用哪个完全取决于你,但是在同等条件下应该首选ContextLoaderListener;对于更多兼容性的信息,请查看ContextLoaderServlet的JavaDoc。
你可以象下面那样使用ContextLoaderListener来注册一个ApplicationContext:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value>
value可以用 -value> classpath:applicationContext.xml
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!-- or use the ContextLoaderServlet instead of the above listener
<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
-->
监听器首先检查contextConfigLocation参数,如果它不存在,它将使用/WEB-INF/applicationContext.xml作为默认值。如果已存在,它将使用分隔符(逗号、冒号或空格)将字符串分解成应用上下文将位置路径。ContextLoaderServlet同ContextLoaderListener一样使用'contextConfigLocation'参数。
8.1. 使用HttpSessionListener
编写一个OnlineUserListener。
import java.util.List;
import javax.servlet.ServletContext;
import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpSessionListener;
import javax.servlet.http.HttpSessionEvent;
public class OnlineUserListener implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent event) {
}
public void sessionDestroyed(HttpSessionEvent event) {
HttpSession session = event.getSession();
ServletContext application = session.getServletContext();
// 取得登录的用户名
String username = (String) session.getAttribute("username");
// 从在线列表中删除用户名
List onlineUserList = (List) application.getAttribute("onlineUserList");
onlineUserList.remove(username);
System.out.println(username + "超时退出。");
}
}
OnlineUserListener实现了HttpSessionListener定义的两个方法:sessionCreated()和 sessionDestroyed()。这两个方法可以监听到当前应用中session的创建和销毁情况。我们这里只用到 sessionDestroyed()在session销毁时进行操作就可以。
从HttpSessionEvent中获得即将销毁的session,得到session中的用户名,并从在线列表中删除。最后一句向console打印一条信息,提示操作成功,这只是为了调试用,正常运行时删除即可。
为了让监听器发挥作用,我们将它添加到web.xml中:
<listener>
<listener-class>anni.OnlineUserListener</listener-class>
</listener>
以下两种情况下就会发生sessionDestoryed(会话销毁)事件:
1.执行session.invalidate()方法时。
既然LogoutServlet.java中执行session.invalidate()时,会触发sessionDestory()从在线用户 列表中清除当前用户,我们就不必在LogoutServlet.java中对在线列表进行操作了,所以LogoutServlet.java的内容现在是 这样。
public void doGet(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException{
// 销毁
session request.getSession().invalidate();
// 成功
response.sendRedirect("index.jsp");
}
}
2.如果用户长时间没有访问服务器,超过了会话最大超时时间,服务器就会自动销毁超时的session。
会话超时时间可以在web.xml中进行设置,为了容易看到超时效果,我们将超时时间设置为最小值。
<session-config>
<session-timeout>1</session-timeout>
</session-config>
时间单位是一分钟,并且只能是整数,如果是零或负数,那么会话就永远不会超时。
对应例子在08-01,为了验证OnlineUserListener是否能正常执行,我们可以登录两个用户,其中一个点击注销,另一个等待一分钟,然后可以在console中看到输出的信息。
8.2. 使用HttpSessionBindingListener
HttpSessionBindingListener虽然叫做监听器,但使用方法与HttpSessionListener完全不同。我们实际看一下它是如何使用的。
我们的OnlineUserBindingListener实现了HttpSessionBindingListener接口,接口中共定义了两个方法:valueBound()和valueUnbound(),分别对应数据绑定,和取消绑定两个事件。
所谓对session进行数据绑定,就是调用session.setAttribute()把HttpSessionBindingListener保存进session中。我们在LoginServlet.java中进行这一步。
// 把用户名放入在线列表session.setAttribute("onlineUserBindingListener", new OnlineUserBindingListener(username));这就是HttpSessionBindingListener和HttpSessionListener之间的最大区别:
>HttpSessionListener只需要设置到web.xml中就可以监听整个应用中的所有session。
>HttpSessionBindingListener必须实例化后放入某一个session中,才可以进行监听。
从监听范围上比较,HttpSessionListener设置一次就可以监听所有session,HttpSessionBindingListener通常都是一对一的。
正是这种区别成就了HttpSessionBindingListener的优势,我们可以让每个listener对应一个username,这样就不需要每次再去session中读取username,进一步可以将所有操作在线列表的代码都移入listener,更容易维护。
valueBound()方法的代码如下:
public void valueBound(HttpSessionBindingEvent event) {
HttpSession session = event.getSession();
ServletContext application = session.getServletContext();
// 把用户名放入在线列表
List onlineUserList = (List) application.getAttribute("onlineUserList");
// 第一次使用前,需要初始化
if (onlineUserList == null) {
onlineUserList = new ArrayList();
application.setAttribute("onlineUserList", onlineUserList);
}
onlineUserList.add(this.username);
}
username已经通过构造方法传递给listener,在数据绑定时,可以直接把它放入用户列表。
与之对应的valueUnbound()方法,代码如下:
public void valueUnbound(HttpSessionBindingEvent event) {HttpSession session = event.getSession();ServletContext application = session.getServletContext();// 从在线列表中删除用户名List onlineUserList = (List) application.getAttribute("onlineUserList");onlineUserList.remove(this.username);System.out.println(this.username + "退出。");}这里可以直接使用listener的username操作在线列表,不必再去担心session中是否存在username。
valueUnbound的触发条件是以下三种情况:
1.执行session.invalidate()时。
2.session超时,自动销毁时。
3.执行session.setAttribute("onlineUserListener", "其他对象");或session.removeAttribute("onlineUserListener");将listener从session中删除时。
因此,只要不将listener从session中删除,就可以监听到session的销毁。
Log4jConfigListener简介
使用spring中的Log4jConfigListener有如如下好处:
1. 动态的改变记录级别和策略,不需要重启Web应用,如《Effective Enterprise Java》所说。
2. 把log文件定在 /WEB-INF/logs/ 而不需要写绝对路径。
因为 系统把web目录的路径压入一个叫webapp.root的系统变量。这样写log文件路径时不用写绝对路径了.
log4j.appender.logfile.File=${webapp.root}/WEB-INF/logs/myfuse.log
3. 可以把log4j.properties和其他properties一起放在/WEB-INF/ ,而不是Class-Path。
4.log4jRefreshInterval为60000表示 开一条watchdog线程每60秒扫描一下配置文件的变化;
在web.xml 添加
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>WEB-INF/log4j.properties</param-value>
</context-param>
<context-param>
<param-name>log4jRefreshInterval</param-name>
<param-value>60000</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
http://blog.csdn.net/andymu077/article/details/6247390
http://blog.csdn.net/dhmpgt/article/details/11734883