Pushlets的初始化陷阱

Pushlets是在类名为Pushlet的servlet的init方法中进行初始化的。一般我们会在web.xml配置pushlet的时候，指定其servlet在Web应用启动时就进行初始化，即便这样，还是有可能初始化失败，导致整个Pushlets失效。Pushlet.init代码如下：

 public void init()
     throws ServletException
   {
     try
     {
       String webInfPath = getServletContext().getRealPath("/") + "/WEB-INF";
       Config.load(webInfPath);

       Log.init();

       Log.info("init() Pushlet Webapp - version=" + Version.SOFTWARE_VERSION + " built=" + Version.BUILD_DATE);

       SessionManager.getInstance().start();

       Dispatcher.getInstance().start();

       if (Config.getBoolProperty("sources.activate"))
         EventSourceManager.start(webInfPath);
       else
         Log.info("Not starting local event sources");
     }
     catch (Throwable t) {
       throw new ServletException("Failed to initialize Pushlet framework " + t, t);
     }
   }

Pushlet.init()源代码

Pushlet类的初始化方法首先会加载Pushlets配置和日志打印组件。其首先调用的Config.load()方法会在class path及WEB-INF中查找pushlet.properties配置文件，并加载所有配置项。这一步至关重要，因为Pushlet会根据配置项决定如何实例化controller、dispatcher、session manager、session、subscriber、subscription这些核心类以及日志类，默认的配置指向这些类的默认实现。事实上，Pushlets正是通过pushlet配置文件来实现其扩展性和灵活性的。如果Pushlets的默认实现无法满足你的业务要求，你可以添加自己的实现，只要继承自Pushlet默认的实现，然后重写其中的某个方法即可。

举个例子，如果要实现Pushlet点对点推送消息，需要知道被推送的对象，因而需要“固定”住Pushlet产生的pushlet session id（有别于web的session id，是有pushlet自己产生和维护的，默认的实现是一串随机字符串），在网上搜索的有些实现是直接修改Pushlets的源代码直接改写SessionManager的createSession来生成跟用户ID强绑定的pushlet session id，例如直接使用用户ID作为pushlet session id，实际上不需要修改Pushlets的源码这么暴力，可以继承SessionManager实现自己的MySessionManager并重写createSessionId方法来返回用户ID，然后在pushlet.properties配置文件中将sessionmanager.class=nl.justobjects.pushlet.core.SessionManager配置项改写为我们自己的实现例如com.test.MySessionManager。这样的实现方式可以比较好的将我们自己的业务代码与开源组件的代码分离，至少在Pushlets.jar版本升级的时候（为了使用新功能或修复bug），能够省去不少合并代码的麻烦。

回头来说Pushlets的初始化陷阱，Dispatcher提供broadcast、multicast、unicast来进行消息的广播、多播和单播，这都会调用到SessionManager类。而Dispatcher和SessionManager都是单例实现，通过getInstance来获取自身对象的引用，它是采用一段静态代码来实现单例创建的，SessionManager的实例化代码如下

  static
  {
    try
    {
      instance = (SessionManager)Config.getClass("sessionmanager.class", "nl.justobjects.pushlet.core.SessionManager").newInstance();
      Log.info("SessionManager created className=" + instance.getClass());
    } catch (Throwable t) {
      Log.fatal("Cannot instantiate SessionManager from config", t);
    }
  }

这段代码只会在程序第一次引用SessionManager时执行一次，如果我们的业务代码在调用Dispatcher类的相应方法执行消息推送（不管是广播、多播还是单播）的时候，系统尚未调用Pushlet.init方法初始化Pushlets，那么就会因为配置尚未加载而造成instance对象创建失败，其后整个Pushlets都是瘫痪的，虽然应用程序能够成功启动，但消息推送的功能就是失效的。例如，我们采用Spring框架的时候，一般是配置org.springframework.web.context.ContextLoaderListener来装载Spring框架，这样一来Spring框架会在Pushlet servlet之前初始化完成。在这个空挡如果业务逻辑触发了Pushlets消息推送，就将导致Dispatcher、SessionManager类的静态代码块被执行。虽然随后Pushlet.init方法会加载配置项，但关于如何创建核心类实例的配置项将不会再被使用。