Spring 与 Jboss

Question

对于企业 Web 应用程序，Spring 与 Jboss 的优缺点是什么。

Answer 1

这是个好问题。有些人在这里错误地指出这是一个苹果与橘子的比较，即 Jboss 是一个容器，而 Spring 只是一个框架，就像 Struts 一样。然而，这有点令人困惑的原因是 JBoss 和 Spring 都从它们最初的简单起源大大扩展，因此彼此越来越接近。一个简单的理解JBoss的方式是原来的名字是“EJBoss”，它的目的是作为一个开源的J2EE应用服务器，所以它作为一个EJB容器比tomcat有优势，因此可以与WebSphere竞争和其他专有应用服务器。

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

但是，随着它们的流行，这两种产品都得到了扩展。例如，JBoss 现在拥有自己的 IoC 容器: JBoss IoC

JBoss provides its own lightweight IoC container called: JBossMicrocontainer. JBoss Microcontainer is a lightweight, Inversion ofControl/Dependency Injection container similar in concept to Spring,Pico Container, and Plexus.

虽然 Spring 可以很好地运行，与 JBoss(大部分)愉快地共存，但它不需要成熟的 EJB 容器，它可以在 tomcat 中轻松运行。 Spring 的整个设计目标是基于轻量级设计的思想，使用 POJO，并且不需要重量级的容器，这与 EJB 非常矛盾，因此看起来与 JBoss 格格不入。

Rod Johnson已经指出没有理由不能在 JBoss 中运行 Spring:

Spring is designed to work in any application server (or outside anapplication server); using Spring does not mean ignoring what theserver may have to offer. It just provides greater choice in a lot ofcases.

因此，您必须决定要使用这两个系统的哪些部分，以及要遵守哪些 Java 标准。根据这篇文章，在 JBoss and Spring ，其中涵盖了它们对标准的遵守程度，看起来，根据您选择的技术，您正在选择一方，因为这似乎是一场颇具争议的战斗。

What comes next is anything but detente, as JBoss and Spring Sourcebattle over everything from XML to integration to tools to eventuallyvirtualization, itself....its a healthy competition,

[snip]

Only time will tell, but i think that this battle only makes thingsbetter for developers, more choices rather than .Net, and moreinnovation around Java, it will be a tough test for JBoss, but onethat they can handle if execution is flawless, otherwise, look forSpring Source to drive a wedge between perceived and real advantagesof JEE 6...sooner, rather than later, portability of applications willhave to be demonstrated in order to counter the proprietary models,and that has not happened,

如需了解遵守各种 Java 标准的最新信息，请查看 request for feedback on Spring 5 .您可以了解 Spring 设计人员面临的限制，同时还强调了一个事实，即对于 Spring 市场，确保 Spring 支持各种 EE 服务器很重要:

We intend to softly upgrade the EE baseline as well. Now, this is abit tricky since we effectively have individual requirements here -and we need to consider the enterprise adoption levels in productionenvironments:

We’ll definitely raise to Servlet 3.0+ (from our present Servlet 2.5runtime compatibility) but no higher since we’d like Spring 5applications to run on EE 6 baselined servers still. See my previousblog post for a discussion on why this is unavoidable, given themarket situation with Java EE 7 and the multitude of servers which isstill based on the Servlet 3.0 API.[snip] It’s just ashame that we have to keep supporting the 2002-era JMS 1.1 API… We’dlike to raise to JPA 2.1+ and Bean Validation 1.1+ but our hands seemto be tied: TomEE 1.7 and JBoss EAP 6.4 have hard JPA 2.0 and BeanValidation 1.0 APIs in them, and WebLogic 12.1.3 has JPA 2.1 but noBean Validation 1.1 API (despite them being related).