在上一篇文章OpenNMS全接触-系统启动(四)中,提到
从%opennms_home%/etc目录下的service-configuration.xml中的所有service,将所有配置的service生成其实例对象 |
这句话其实在代码中隐藏了很多比较玄奥的工作,下面将介绍这些对象究竟被怎样创建,它又引发了哪些操作。
我们以一个例子来看一下吧,在service-configuration.xml文件中,我们可以看到name为OpenNMS:Name=Collectd的service,其class-name定义为org.opennms.netmgt.collectd.jmx.Collectd,通过前面的介绍,我们知道系统在启动后会生成该类的一个实例。但等我们打开该类的定义后却发现,其实该类并没有什么内容:
- package org.opennms.netmgt.collectd.jmx;
- import org.opennms.netmgt.daemon.AbstractSpringContextJmxServiceDaemon;
- public class Collectd extends AbstractSpringContextJmxServiceDaemon implements
- CollectdMBean {
- @Override
- protected String getLoggingPrefix() {
- return "OpenNMS.Collectd";
- }
- @Override
- protected String getSpringContext() {
- return "collectdContext";
- }
- }
我们已经知道Collectd负责定期收集网络设备性能数据,可从这里我们看不到任何它做的工作。
所以只能沿着基类网上找,让我们看下AbstractSpringContextJmxServiceDaemon的内容吧,在这里我们
可以找到所有的答案。
我曾经一直疑惑于OpenNMS-service中命名定义了好多*-context.xml文件,却始终没有看到在哪里加载这些
context的定义文件,但事实又告诉我它们肯定被加载了,因为我已经在代码中使用过这些context中定义的
bean了,程序员的最大痛苦莫过于知道用一个东西,却又不知道它怎么来的了。后来终于在这个地方找到了答案。
因为在AbstractSpringContextJmxServiceDaemon中我终于看到了熟悉的代码:
- protected ApplicationContext getContext() {
- return m_context;
- }
是的,有了context,对spring来说,就有了一切。
在onInit中我们终于看到它对该context的初始化了
- m_context = BeanUtils.getFactory(getSpringContext(), ClassPathXmlApplicationContext.class);
嗯,从上面的Collectd中我们已经看到了对于getSpringContext()的覆写,是的,通过该名字,终于在opennms-service中找到了该bean,它对应的context文件在applicationContext-collectd.xml文件中。而
- public T getDaemon() {
- return (T) m_context.getBean(DAEMON_BEAN_NAME, SpringServiceDaemon.class);
- }
终于通过bean的名称(daemon)来加载真正干活的家伙了,因为我们从applicationContext-collectd.xml文件中已经看到了那个默默无闻却承受所有工作的人,
- <bean id="daemon" class="org.opennms.netmgt.collectd.Collectd">
在start函数中正是通过获取这个名为"daemon"的bean来调用其start()方法来让其run起来的。而它的init()方法则是因为基类AbstractServiceDaemon继承了InitializingBean接口,在实现该接口的afterPropertiesSet()方法时,调用了init()方法,从而保证了在该bean的属性初始化后调用init()方法。
转载于:https://blog.51cto.com/njulinq/281914