吹弹得破是重回一人犯错，全家光荣的老路

robbin能不能给点改进的意见？因为springside的插件定位是让大家可以各取所需，快速定位到自己关心的东西上，而且尽量降低其他东西对他的干扰。 在这种前提下，设计目标就是尽量使用目前的机制，大家可以直接copy到自己项目中的，而不是自己搞一个tonic之类的插件机制，别人如果要copy ss里的东西还要装个插件框架就不合算了。

白衣的问题就是不应该拿spring load xml的机制来当plugin来用。这种plugin本来用起来就太危险，把你应用完全依赖到plugin上面去了。一个合理的plugin机制必须能够有良好的验证机制，验证插上来的plugin是否符合要求的格式。而且plugin提供的功能也不应该是无限制的，必须基于你的plugin manager提供出来的API接口上。所以plugin机制不好做。我觉得可以好好研究一下tonic和confluence。特别是应该看看Mike Cannon-Brookes的ppt：
http://www.iteye.com/pages/viewpage.action?pageId=968

spring配置文件首先起码需要按照层去划分，然后如果模块比较多，还可以继续按照模块划分

生产环境和测试环境的大部分xml配置都可以公用，但是数据库配置分开各用各的。

那你需要的就不是plugin机制，而是一个模板生成工具，我选择需要的功能，然后你生成包含我选择功能的那些代码。

我以前也是这么做的，感觉不够快，不能随心所欲地运行test，现在我用spring的org.springframework.test.AbstractTransactionalDataSourceSpringContextTests，创建/drop表，导入测试数据，初始化spring容器都只需要一次，在我这59个操作数据库的integration test method只需要不到9秒就完成，完整的一次编译/测试/生成测试报告只需要17秒左右，包含99个java class，27个test class(98个test method)

你这不叫做单元测试。你启动数据库以后，连续做59个测试，前面的测试数据会影响到后面的测试结果。

我之所以慢一点，其实并不是慢在初始化spring容器上面了，而是慢在每个test都需要反复drop/create table上面了。

当然，也可以我每次test之后，test方法自己负责清理测试数据。但是你只要hold spring容器，就无法避免Hibernate二级缓存的影响。所以还是test之间有相关性，最好的办法就是每个test  drop/create db.

看了robbin的测试方法，感觉很不错，和我测试的思路差不多。不过目前在对Service层的测试中，那些Checked Exception有时候令我比较头痛。因为我是比较喜欢在Service层抛Checked Exception，然后由Webwork的Interceptor去截获处理的。我认为Checked Exception应该作为一个异常事件流的表现方式而存在。那么在Service层的测试中，如何能保证测试的完整性呢？具体的说，就是如何让一个测试既能覆盖到正常事件流，又能覆盖到异常时间流？

不过我也可以考虑试一下这样的办法，一直hold spring容器，然后test自己清理数据，清理缓存。

spring会帮你回滚事务的，所以不会相互影响。
二级缓存我倒没有考虑，我想开启/关闭两种情况都可以测一下，我现在是只测了开启的情况，应该也可以了，毕竟真正生产的时候是开启的。

你没有理解我的意思，不过也没有关系，我可以手工清理 sessionFactory.evict(...);

根据我们以前对于异常的讨论，我想有一点是明确的，所有的业务异常都应该是RuntimeException的。

不过不管是不是CheckedException，你当然可以测试异常流了，例如

try {
...
fail(...);

}catch (...Exception e) {
  
}

一旦无法捕获异常，assert就fail了。