一。Spring的xml配置很不好。xml滥用程度已经泛滥成灾了。要知道程序员最习惯，最欢迎的还是看代码。当要看一个业务逻辑时发现竟然先要去看它的父类，然后看爷爷类，然后再看太爷爷类，最后发现还需要找Spring配置去找另外一个类，而这个类ref了另外一个类时，肯定哐当晕倒(不知道还有没有父，爷，太爷)。无论是初学语言，还是对技术深入了解的高手，或者还是因为项目紧急从别的地方抽掉过来的其他成员。简单的代码和配置都是合适的(像我这样用了好几年的java的人已经有点不爱看xml配置)。
二。Spring的配置方式不支持开发模式。每次修改Spring配置，总是需要重启动。一些大项目启动是非常耗时的。相反一些别的小的第三方配置开发包可以支持开发模式。另外，我觉得Sping也不太可能支持开发模式，这在下面一点会说到
三。直觉上Spring管的太多。对于很多框架或者第三方lib来说，往往专著于完成系统的某一方面。如Hibernate专著于O/R Mapping,EJB专著于分布，事务，规则引擎专著于解释规则，执行运算等。Spring做的太多使其有啥都做不好的嫌疑，当然这还不是最主要的负面因素，而是他干扰了业务系统。他对对象进行管理有可能会让某些用户用Spring管理业务对象。这有可能带来负面结果的。如一些情况：Struts的MVC被Spring接管，业务逻辑又被Spring接管。一个新手很难看懂代码。了解代码的时候总会遇到“黑洞”。又如上面所说的开发模式，因为业务对象的互相依赖，"重新启动业务对象"是很复杂的一件事情，Spring也不可能做到这一点。除非你的业务对象屈服于Spring的架构，这又和使用Spring初衷违背了。再如，业务对象的复杂性，核心性决定了Spring难以管理好它，也没有必要多此一举.
四。适配器成灾。Spring为了管理好第三方包，只好做些适配器。以方便管理。当然，有些第三方包很简单，不需要做，比如我看到javaresearch.org刚有的一篇文章是在Spring中使用定时器。但是某些复杂的第三方包或者框架就有问题了，得写适配器。如接管某web mvc框架。又如刚才所说的定时器lib，本生功能齐备的定时器lib就有自己的配置，你要去Spring去管理它。只能写个适配器，在适配器中使用定时器lib提供的配置文件
