在3.0版本中,对一些容器的生命周期的处理做了不小的改变,包括:
- DefaultMessageListenerContainer
- GenericMessageEndpointManager
- JmsMessageEndpointManager
- SchedulerFactoryBean
- SimpleMessageListenerContainer
这些容器实现了一个叫SmartLifecycle的新接口,能够自动启动。看名字就很智能,它用一种新的方式来管理启动顺序,在application context初始化结束后,开始初始化这些容器,如果isAutoStartup()为true,通过getPhase()来确认启动顺序,值越小就优先启动,关闭时相反,下面是实现:
private void startBeans(boolean autoStartupOnly) {
Map<String, Lifecycle> lifecycleBeans = getLifecycleBeans();
Map<Integer, LifecycleGroup> phases = new HashMap<Integer, LifecycleGroup>();
for (Map.Entry<String, ? extends Lifecycle> entry : lifecycleBeans.entrySet()) {
Lifecycle lifecycle = entry.getValue();
if (!autoStartupOnly || (lifecycle instanceof SmartLifecycle && ((SmartLifecycle) lifecycle).isAutoStartup())) {
int phase = getPhase(lifecycle);
LifecycleGroup group = phases.get(phase);
if (group == null) {
group = new LifecycleGroup(phase, this.timeoutPerShutdownPhase, lifecycleBeans);
phases.put(phase, group);
}
group.add(entry.getKey(), lifecycle);
}
}
if (phases.size() > 0) {
List<Integer> keys = new ArrayList<Integer>(phases.keySet());
Collections.sort(keys);
for (Integer key : keys) {
phases.get(key).start();
}
}
}
可以看到根据phase的值,分组到LifecycleGroup中,然后自然排序,调用start()方法初始化(无视bean的lazy-init为true)。默认phase的值设为Integer.MAX_VALUE,说明是最晚进行处理的。
这种处理方式非常优雅,但依赖于Spring2.5版本的项目迁移过来时,问题就来了。其实项目中已经实现了类似上面的处理流程,就是注册一个ContextRefreshedEvent事件监听器,事件触发时说明容器已经初始化结束了,使用的是DefaultMessageListenerContainer,这个容器需要通过编程方式实例化的,而不是配置在xml文件中,这样更加灵活。在2.5版本中,DefaultMessageListenerContainer的afterPropertiesSet()方法会调用doStart()开始接收消息,但在3.0版本中由于流程改变,下面这段代码在initialize()中已经被去掉:
if (this.autoStartup) {
doStart();
}
doInitialize();
而生命周期是先于ApplicationEvent前执行的,看下面代码就很清楚了:
protected void finishRefresh() {
// Initialize lifecycle processor for this context.
initLifecycleProcessor();
// Propagate refresh to lifecycle processor first.
getLifecycleProcessor().onRefresh();
// Publish the final event.
publishEvent(new ContextRefreshedEvent(this));
}
这样,这样处理的之后,问题就来了:
本来在创建单例对象回调afterPropertiesSet()中开始接受消息,现在延后了
spring准备在SmartLifecycle中初始化DefaultMessageListenerContainer准备接受消息时,由于对象是在ContextRefreshedEvent中创建的,此时getLifecycleBeans()还没有任何bean
触发ContextRefreshedEvent事件后需要的对象都创建好了,spring已经不鸟你了
这样的结果是整个流程中没有没有知道到DefaultMessageListenerContainer的start()方法,所有程序启动后不会监控任何的MQ服务器。
问题找到了,解决就简单了(大半个下午也没了-_-!),用spring的SmartLifecycle方式来处理,以前的那陀实现删光光。