Tomcat启动时加载数据到缓存--Web.xml里listener的加载顺序,优先初始化Spring IOC容器 http://fengbin2005.iteye.com/blog/2065336 Tomcat启动时加载数据到缓存--Web.xml里listener的加载顺序,优先初始化Spring IOC容器

最近用到在Tomcat服务器启动时自动加载数据到缓存,这就需要创建一个自定义的缓存监听器并实现ServletContextListener接口,并且在此自定义监听器中需要用到Spring的依赖注入功能.在web.xml文件中监听器配置如下:

 

Xml代码  
  1. <listener>  
  2.         <listener-class>  
  3.             org.springframework.web.context.ContextLoaderListener  
  4.         </listener-class>  
  5. </listener>  
  6. <listener>  
  7.     <listener-class>  
  8.         com.wsjiang.test.listener.CacheListener  
  9.     </listener-class>  
  10. </listener>  

 

      上面的配置细细大意为,先配置spring监听器,启动spring,再配置一个缓存监听器,我希望他们是顺序执行的,因为在缓存监听器中需要 spring注入其他对象的实例,我期望在服务器加载缓存监听器前加载Spring的监听器,将其优先实例化。但是实际运行发现他们并不是按照配置的顺序 加载的。


      对上面的问题我查询了很多资料,找到了一种解决方案,希望能帮助遇到同类问题的朋友。
      思路就是,既然listener的顺序是不固定的,那么我们可以整合两个listener到一个类中,这样就可以让初始化的顺序固定了。我就重写了 org.springframework.web.context.ContextLoaderListener这个类的 contextInitialized方法.大致代码如下:

Java代码  
  1. public class ContextLoaderListenerOverWrite extends ContextLoaderListener {  
  2.     private IStationService stationService;  
  3.     private IOSCache osCache;  
  4.     @Override  
  5.     /** 
  6.      * @description 重写ContextLoaderListener的contextInitialized方法 
  7.      */  
  8.     public void contextInitialized(ServletContextEvent event) {  
  9.         super.contextInitialized(event);  
  10.         ApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(event.getServletContext());  
  11.         //获取bean  
  12.         stationService = (IStationService) applicationContext.getBean("stationService");   
  13.         osCache = (IOSCache) applicationContext.getBean("osCache");  
  14.         /* 
  15.          具体地业务代码 
  16.          */  
  17.     }  
  18. }  

 

      web.xml的配置就由两个listener变为一个:

Xml代码  
  1. <listener>  
  2.     <listener-class>  
  3.                  com.wsjiang.test.listener.ContextLoaderListenerOverWrite  
  4.         </listener-class>  
  5. </listener>  

       这样就能保证Spring的IOC容器先于自定义的缓存监听器初始化,在缓存监听器加载的时候就能使用依赖注入的实例.

最近用到在Tomcat服务器启动时自动加载数据到缓存,这就需要创建一个自定义的缓存监听器并实现ServletContextListener接口,并且在此自定义监听器中需要用到Spring的依赖注入功能.在web.xml文件中监听器配置如下:

 

Xml代码  
  1. <listener>  
  2.         <listener-class>  
  3.             org.springframework.web.context.ContextLoaderListener  
  4.         </listener-class>  
  5. </listener>  
  6. <listener>  
  7.     <listener-class>  
  8.         com.wsjiang.test.listener.CacheListener  
  9.     </listener-class>  
  10. </listener>  

 

      上面的配置细细大意为,先配置spring监听器,启动spring,再配置一个缓存监听器,我希望他们是顺序执行的,因为在缓存监听器中需要 spring注入其他对象的实例,我期望在服务器加载缓存监听器前加载Spring的监听器,将其优先实例化。但是实际运行发现他们并不是按照配置的顺序 加载的。


      对上面的问题我查询了很多资料,找到了一种解决方案,希望能帮助遇到同类问题的朋友。
      思路就是,既然listener的顺序是不固定的,那么我们可以整合两个listener到一个类中,这样就可以让初始化的顺序固定了。我就重写了 org.springframework.web.context.ContextLoaderListener这个类的 contextInitialized方法.大致代码如下:

Java代码  
  1. public class ContextLoaderListenerOverWrite extends ContextLoaderListener {  
  2.     private IStationService stationService;  
  3.     private IOSCache osCache;  
  4.     @Override  
  5.     /** 
  6.      * @description 重写ContextLoaderListener的contextInitialized方法 
  7.      */  
  8.     public void contextInitialized(ServletContextEvent event) {  
  9.         super.contextInitialized(event);  
  10.         ApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(event.getServletContext());  
  11.         //获取bean  
  12.         stationService = (IStationService) applicationContext.getBean("stationService");   
  13.         osCache = (IOSCache) applicationContext.getBean("osCache");  
  14.         /* 
  15.          具体地业务代码 
  16.          */  
  17.     }  
  18. }  

 

      web.xml的配置就由两个listener变为一个:

Xml代码  
  1. <listener>  
  2.     <listener-class>  
  3.                  com.wsjiang.test.listener.ContextLoaderListenerOverWrite  
  4.         </listener-class>  
  5. </listener>  

       这样就能保证Spring的IOC容器先于自定义的缓存监听器初始化,在缓存监听器加载的时候就能使用依赖注入的实例.

猜你喜欢

转载自usench.iteye.com/blog/2231856