hivemodule的设置问题
介绍
HiveMind是一个服务（services）和配置（configuration）的微内核。
HveMind设计的目的是使编码变得尽可能简洁和无痛苦。在根本上因为服务是处于同一个虚拟机的简单对象（POJOs--plain old java objects），J2EE里面所有复杂的地方都可以忽略，比方说没有了JNDI查找，没有了远程异常，没有了home和remote接口。当然，你仍然可以用HiveMind来处理EJBs。在这种这种情况下，服务将负责在请求EJB之前执行JNDI查找等（它们本身拥有很多数据）。
在任何情况下，代码应该尽可能简短。外部对象代码（不由HiveMind管理的对象，像servlet）获取服务的方式就非常的自然。
你的代码需要负责的有：
- 获取一个注册过的单例服务的引用li>
- 知道获取服务的完整IDli>
- 将接口类型做为参数传入
HiveMind需要负责的有：
- 查找服务，在必要时创建服务
- 检查服务类型和你代码里期望的类型
- 执行严格的线程安全策略
- 准确，详细的报告错误
- HiveMind方法
让HiveMind为你的服务添加一个拦截器。拦截器将统一的为函数的进入退出和函数中抛出的异常记录日志信息。
下面的描述符片段定义了一个服务。描述符不仅规定了服务的实现（使用<create-instance></create-instance>标签），还为函数添加了一个拦截器（使用<interceptor></interceptor>）
- "MyService" interface="com.myco.MyServiceInterface"> class="com.myco.impl.MyServiceImpl"/> "hivemind.LoggingInterceptor"/>
任务对比：引用其它服务
传统方法
private SomeOtherService _otherService;
public String myMethod(String param)
{
if (_otherService == null)
_otherService = // Lookup other service . . .
_otherService.doSomething(. . .);
. . .
}
如何查找其它服务会在应用运行环境中定义；可以通过JNDI查找一个EJB；像Avalon等其它的微内核框架会调用一个特殊的API。
另外，这些代码不是线程安全的；对个线程可能同时执行，引起不期望的（甚至灾难性的）对其它服务的重复查找。
HiveMind方法
让HiveMind帮你将其它服务作为一个属性插入。这就是依赖注入。HiveMind可以通过JavaBeans属性和构造方法参数的形式完成依赖注入。
private SomeOtherService _otherService;
public void setOtherService(SomeOtherService otherService)
{
_otherService = otherService;
}
public String myMethod(String param)
{
_otherService.doSomething(. . .);
. . .
}
HiveMind使用代理机制来延迟服务的构造，直到真正需要时才会真正构造服务。赋给其它服务的代理对象会在服务方法第一次调用时构造实际的服务并对它进行配置工作。可喜的是这些都是在线程安全的前提下完成的。
任务对比：读取配置信息
传统方法
找到一个资源文件或XML文件（在类路径还是文件系统？），读取它，然后编写代码解析原始数据并将它们转化为适当的Java对象。
这种缺乏标准的方法会使数据驱动的解决方案变得非常麻烦而且不像预期的那样有价值，带来的往往是代码膨胀和缺乏灵活性。
即便是使用XML文件进行配置，读取内容的代码也往往是低效的，缺乏测试的，并且缺少了HiveMind的错误检查能力。
HiveMind方法
private List _configuration;
public void setConfiguration(List configuration)
{
_configuration = configuration;
}
public void myMethod()
{
Iterator i = _configuration.iterator();
while (i.hasNext())
{
MyConfigItem item = (MyConfigItem)i.next();
item.doStuff(. . .);
}
}
HiveMind能用配置扩展点的内容设置需要配置的属性。上例中list里的数据是从申明了的配置构造的，并由HiveMind转化为对象。和服务一样，配置也是线程安全的，延迟构造的。
任务对比：测试服务
传统方法
使用像EJB容器这样的复杂环境，你必须首先部署你的代码然后在从外部测试它。EJB代码难于测试的原因就在于协同工作的EJBs需要使用JNDI去获取对方。如果只想测试应用程序局部的话就非常难办到了。
HiveMind方法
让代码可测试是HiveMind关注一个重点，在它的测试策略里面可以体现这一点。
- 因为HiveMind服务是普通对象（POJOs）,你的测试用例可以很容易的直接实例化它。
- HiveMind服务是用接口来定义的，所以可以很容易的编写一个虚假的实现。
- 服务的协同是通过依赖注入完成的，所以测试用例可以很容易的编写真实的或虚假的协同工作的服务实现。
- 因为配置数据仅仅是Java对象的集合，所以测试用例可以很容易的编写一个适合于测试的对象集合。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1445004