在上一篇文章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，通过前面的介绍，我们知道系统在启动后会生成该类的一个实例。但等我们打开该类的定义后却发现，其实该类并没有什么内容：

 

   
   
   
   
    
    
    
    
    
  1. package org.opennms.netmgt.collectd.jmx; 
    2. 
    
    
    
    
  2.  
    3. 
    
    
    
    
  3. import org.opennms.netmgt.daemon.AbstractSpringContextJmxServiceDaemon; 
    4. 
    
    
    
    
  4.  
    5. 
    
    
    
    
  5. public class Collectd extends AbstractSpringContextJmxServiceDaemon implements 
    6. 
    
    
    
    
  6.         CollectdMBean { 
    7. 
    
    
    
    
  7.  
    8. 
    
    
    
    
  8.     @Override 
    9. 
    
    
    
    
  9.     protected String getLoggingPrefix() { 
    10. 
    
    
    
    
  10.         return "OpenNMS.Collectd"; 
    11. 
    
    
    
    
  11.     } 
    12. 
    
    
    
    
  12.  
    13. 
    
    
    
    
  13.     @Override 
    14. 
    
    
    
    
  14.     protected String getSpringContext() { 
    15. 
    
    
    
    
  15.         return "collectdContext"; 
    16. 
    
    
    
    
  16.     } 
    17. 
    
    
    
    
  17.  
    18. 
    
    
    
    
  18. }
    19. 
   
   
   
   
我们已经知道Collectd负责定期收集网络设备性能数据，可从这里我们看不到任何它做的工作。
所以只能沿着基类网上找，让我们看下AbstractSpringContextJmxServiceDaemon的内容吧，在这里我们
可以找到所有的答案。
我曾经一直疑惑于OpenNMS-service中命名定义了好多*-context.xml文件，却始终没有看到在哪里加载这些
context的定义文件，但事实又告诉我它们肯定被加载了，因为我已经在代码中使用过这些context中定义的
bean了，程序员的最大痛苦莫过于知道用一个东西，却又不知道它怎么来的了。后来终于在这个地方找到了答案。
因为在AbstractSpringContextJmxServiceDaemon中我终于看到了熟悉的代码：
 
    
    
    
    
    
     
     
     
     
  1. protected ApplicationContext getContext() { 
    2. 
     
     
     
     
  2.         return m_context; 
    3. 
     
     
     
     
  3.     } 
    4. 
    
    
    
    
是的，有了context，对spring来说，就有了一切。
在onInit中我们终于看到它对该context的初始化了
 
     
     
     
     
    
      
      
      
      
  1. m_context = BeanUtils.getFactory(getSpringContext(), ClassPathXmlApplicationContext.class); 
    2. 
     
     
     
     
嗯，从上面的Collectd中我们已经看到了对于getSpringContext()的覆写，是的，通过该名字，终于在opennms-service中找到了该bean，它对应的context文件在applicationContext-collectd.xml文件中。而
 
      
      
      
      
    
       
       
       
       
  1. public T getDaemon() { 
    2. 
       
       
       
       
  2.         return (T) m_context.getBean(DAEMON_BEAN_NAME, SpringServiceDaemon.class); 
    3. 
       
       
       
       
  3.     } 
    4. 
      
      
      
      
终于通过bean的名称（daemon）来加载真正干活的家伙了，因为我们从applicationContext-collectd.xml文件中已经看到了那个默默无闻却承受所有工作的人，
 
       
       
       
       
    
        
        
        
        
  1. "daemon" class="org.opennms.netmgt.collectd.Collectd"> 
    2. 
       
       
       
       
在start函数中正是通过获取这个名为"daemon"的bean来调用其start()方法来让其run起来的。而它的init()方法则是因为基类AbstractServiceDaemon继承了InitializingBean接口，在实现该接口的afterPropertiesSet()方法时，调用了init()方法，从而保证了在该bean的属性初始化后调用init()方法。