我遇到了一个情况…
我曾被要求就采用哪种方法提供建议，就Spring 3.0和Java EE 6.0之间的Java EE开发而言。我曾经是，现在仍然是Spring 2.5的推动者，特别是在JBoss上，是经典Java EE 5开发的推动者，我什至将旧应用迁移到Spring，并影响了此处对开发策略的重新定义，以包括Spring特定的API，并帮助制定战略计划以培育更轻巧的解决方案，例如Spring + Tomcat，而不是笨重的JBoss，现在，我们只是将JBoss用作Web容器，而我称之为“容器悖论中的容器”，也就是说，在JBoss中运行具有大多数API的Spring应用程序，因此我们正在迁移到tomcat。
但是，随着Java EE 6.0的到来，许多功能使当时的Spring变得有吸引力，易于部署，耦合较少，甚至某种形式的DI等，似乎都以某种方式被模仿了。JSF 2.0，JPA 2.0，WebBeans，WebProfiles等
所以问题来了…
从你的角度来看，鉴于Java EE 6.0提供的新观点，继续投资像Spring这样的非标准Java EE开发框架是多么安全和合理？
我们能否谈谈Spring开发的3年或4年，还是建议你尽早采用Java EE 6.0 API及其实践？
我将不胜感激。
在这方面，由于OpenSource VS很自然，Spring将始终领先于JavaEE。一个标准。因此，一个事实是，与JavaEE相比，Spring可以更早地获得新功能（例如，容器集成测试是JavaEE 6中的一项新功能，并且已经在Spring中使用了很长时间）。
恕我直言，最重要的一点是管理和开发的生命周期之一。当选择JavaEE时，会将编程模型绑定到基础架构。通常，应用服务器供应商并不是采用新标准最快的版本（责备WebSphere，JBoss，你拥有什么）。因此，这意味着我们可能不会在年底之前看到生产准备就绪，大厂商支持JavaEE 6的产品。
即使是这种情况，你仍然必须克服管理，IT部门和预算控制经理的障碍，才愿意升级到此闪亮的新版本。从这一方面来看，JavaEE 6甚至不是许多商店的选择。你可以选择将应用程序部署到哪个平台？你想选择Glassfish生产吗？继续尝试。大多数商店都不是那么“舒适”。
恰恰相反：spring。将编程模型与基础架构分离。使用当前的3.0.x并@Inject在Tomcat或旧版应用程序服务器中使用，JPA 2等。
@Inject
