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

xml文件出错时，是报异常写log 还是停止整个应用启动？各位大佬都力挺Spring现在的净室方法，本来也打算屈服了。但想想还是觉得这和分模块开发的潮流不符，前篇没把事情表述不好，重开一篇。

  A,B,C君分别开发不同模块，A君模块的配置文件错了，所有人就都跑不起应用，一人犯错，全家光荣，值得吗？难道不能让开发团队自己选择daily build，集成测试这类时机来质保吗？

  举一个同质的例子，如果明天Eclipse改成，每次编译都会自动跑一次全部测试用例，如果别人模块里一个测试用例不过，你的代码就编译不了。难道你不会高叫，shit，这关我什么事！！！！

虽然，Eclipse也是很好心的想保证你不会把没通过单元测试的代码编译部署，透明也会说，有人会提交单元测试不过的代码的还叫团队开发么：）

小白还对这个耿耿于怀,可以试试自己实现一个ApplicationContext,

白衣，maybe you need Hivemind。
把SpringSide改为HivemindSide吧，呵呵

那是因为没有相应的惩罚机制。
如果团队里面某个开发人员提交未经测试通过的代码，那么团队其他成员每个人就有权力让此君为自己做一件事，那么这时候你就会开心大笑：哈哈，今天的**有着落了！

程序不能够仅因为一个文件错误就导致整个程序不能运行，只是制度上要尽量防止此类事情的发生。

比如感冒了但人还能工作，同时要经常运动增强身体健康。

团队开发不仅要分模块，还要分层。

ApplicationContext有两类，一类是全局的，一类是模块内才需要的。

我看了一下WebApplicationContext和ContextLoader的代码，它是注册了一个Root的Context到ServletContext里。（为了在Quartz中能访问ApplicationContext  ）
那么我们也可以为不同的模块注册自己的Context，而不与其他人的冲突。
甚至可以继承ContextLoader，使用来为自己的项目初始化Context的。 初始化时，根据配置文件来决定加载的模块（根Context可以直接加载）。

学习定制Spring Framework也是不错地。

ApplicationContext也是可以有继承关系的。想办法让模块内的ApplicationContext由根Context继承而来，模块内仅仅访问自己的ApplicationContext。
然后再隔离开不同模块的Context初始化，这样模块就可以独立测试。


我觉得大家讨论下这个比较好。

我们不这样做的原因是，跑测试需要的时间稍微长了点。

请避免一概而论。这“一个文件”，要分应用的内部文件还是外部文件，是应用的一部分还是业务的一部分。如果是应用程序本身出了错，尽早发现尽早修复是我能想到的最好办法。这是你现有功能中的bug，你为什么要想把它掩盖起来？

另外，我很反对随便打比方。为了证明打比方的随意性和无价值，我也给你打个比方。比如说你出门之前就要检查机票身份证手机钱包笔记本行李箱是不是都带好了，要是走到机场再检查发现没带机票，最起码你得麻烦，更大的可能性是要误飞机。

eclipse plugin: http://pag.csail.mit.edu/continuoustesting/

在你保存java文件时自动运行所有你希望立即执行的junit测试，默认是所有测试，用得很爽，推荐给大家，真正是让你随时随地运行所有测试

问题关键就是, 这不是我现有功能中的bug啊, 是隔壁那条友的模块的，为什么就让我什么都做不了了呢。

虽然可以把那条友的application-context-AAA.xml干掉，但如果还有第2个文件引用了这个文件里定义的bean，spring找不到时又不会注入一个null,而是又报错，停止启动....

所以我还是觉得集成测试的时机可以由用户选择，而不是在每次编译的时候。