这是一个很好的问题。有些人错误地认为这是苹果和橙子之间的比较，即Jboss是一个容器，而Spring只是一个框架，就像Struts一样。然而，这有点令人困惑的原因在于，JBoss和Spring都从它们最初的简单起源中大大扩展了，因此它们越来越接近彼此。理解JBoss的一种简单方法是，它的原始名称是“EJBoss”，旨在成为一个开源的J2EE应用服务器，因此它具有优于tomcat的作为EJB容器的优势，因此可以与WebSphere和其他专有应用服务器竞争。

Spring是一个IoC框架（现在称为“依赖注入”），本质上是对象的工厂，以便您可以遵循更“松散耦合”的设计。

但是，随着它们的普及，两个产品都得到了扩展。例如，JBoss现在拥有自己的IoC容器：

JBoss IoC

JBoss提供了自己的轻量级IoC容器，称为：JBoss

Microcontainer。 JBoss Microcontainer是一个轻量级的，类似于Spring、Pico Container和Plexus的IoC /依赖注入容器。

虽然Spring可以完美地运行，并且与JBoss共存（大多数情况下）相当愉快，但它不需要完整的EJB容器，可以在tomcat中轻松运行。Spring的整个设计目标基于轻量级设计的理念，使用POJO和不需要重量级容器的要求，这与EJB非常相反，因此似乎与JBoss相矛盾。

Rod Johnson指出，在JBoss中运行Spring没有任何理由：

Spring被设计为可以在任何应用服务器（或应用服务器之外）中工作；使用Spring并不意味着忽略服务器可能提供的功能。它只是在许多情况下提供更多选择。

因此，您需要决定要使用两个系统中的哪些部分以及要遵守哪些Java标准。根据这篇关于JBoss和Spring的文章，它涵盖了它们如何遵循标准，似乎取决于您选择哪种技术，您正在选择一个阵营，因为这似乎是一场非常有争议的战斗。

接下来的事情绝不是缓和，因为JBoss和Spring Source在从XML到集成再到工具，最终到虚拟化等方面进行争夺......这是一场健康的竞争，

[省略]

只有时间能说明一切，但我认为这场战斗只会为开发人员带来更好的选择，而不是.NET，并且在Java周围带来更多创新，这将是对JBoss的严峻考验，但如果执行无误，他们可以处理，否则，寻找Spring Source来在JEE 6的感知和实际优势之间制造分歧......很快，应用程序的可移植性将不得不得到证明，以抵消专有模型，而这尚未发生。

如果您想了解关于各种Java标准的遵循情况的更多最新信息，请看一下Spring 5反馈请求。您可以了解Spring设计师面临的限制，同时也突出了对于Spring市场而言，确保Spring支持各种EE服务器的重要性：

我们也打算软升级EE基线。现在，这有点棘手，因为我们实际上在这里有个别的要求 - 我们需要考虑生产环境中的企业采用水平：

我们肯定会升级到Servlet 3.0+（从我们目前的Servlet 2.5运行时兼容性），但不会更高，因为我们希望Spring 5应用程序仍然可以在EE 6基线服务器上运行。请参阅我之前的博客文章，了解为什么这是不可避免的，考虑到Java EE 7的市场状况和仍基于Servlet 3.0 API的众多服务器。

[省略]只是有点遗憾，我们必须继续支持2002年的JMS 1.1 API...我们想升级到JPA 2.1+和Bean Validation 1.1+，但我们的手似乎被束缚住了：Tomee 1.7和JBoss EAP 6.4中有硬性的JPA 2.0和Bean Validation 1.0 API，而WebLogic 12.1.3具有JPA 2.1但没有Bean Validation 1.1 API（尽管它们是相关的）。