java - Spring MVC with JBoss vs Tomcat - 优点/实践

Question

好的。这又是一个行业惯例问题。

• Tomcat = Web 容器
• JBoss、WebLogic 等 = 具有 Web Container 的应用服务器(对于 JBoss，它的 fork Tomcat)

Spring 不需要像 JBoss 这样的应用服务器。如果我们使用 JMS 等企业服务，我们可以使用 RabbitMQ、ApacheMQ 等独立系统。

1. 问题是为什么人们仍然将 JBoss 和其他应用程序服务用于纯基于 Spring 的应用程序？
2. 通过使用应用程序服务器，Spring 可以利用哪些优势？像对象池一样？ Application Server 提供了哪些具体优势？这些是如何配置的？
3. 如果不用于 Spring，应用服务器用于 Spring/Hibernate 等堆栈还有哪些其他用途？ (用例)

Answer 1

实际上我会说监听 JMS 可能是应用服务器的最佳理由。独立的消息代理不能解决问题，因为您仍然需要一个正在监听消息的组件。最好的方法是使用 MDB。理论上你可以使用 Springs MessageListenerContainer。然而，这有几个缺点，比如 JMS 只支持阻塞读取，因此 Spring 需要启动它自己的线程，这完全不支持(即使在 Tomcat 中)，并且可能会破坏事务、安全性、命名(JNDI)和类加载(这反过来会破坏远程)。 JCA 资源适配器可以随意做任何事情，包括通过 WorkManager 启动线程。除了 JMS(或其他目的地)之外，可能还使用了一个数据库，此时您需要 XA 事务和 JTA，换句话说，一个应用程序服务器。是的，您可以将其修补到 servlet 容器中，但此时它与应用服务器无法区分。

恕我直言，反对应用服务器的最大原因是规范发布后需要数年时间(这反过来也需要数年时间)，直到服务器实现规范并消除最严重的错误。直到现在，就在 EE 7 即将发布之前，我们是否有 EE 6 服务器开始出现，它们并没有完全充满错误。一些供应商不再修复其 EE 6 产品线中的错误，因为他们已经忙于即将推出的 EE 7 产品线，这变得可笑了。

编辑

最后一段的详细解释:

Java EE 在很多地方都依赖于所谓的上下文信息。未作为参数从服务器/容器显式传递给应用程序但隐式“存在”的信息。例如当前用户进行安全检查。当前事务或连接。当前用于查找类以延迟加载代码或反序列化对象的应用程序。或者用于进行 JNDI 查找的当前组件(servlet、EJB、...)。所有这些信息都在服务器/容器在调用组件(servlet、EJB、...)之前设置的线程局部变量中。如果您创建自己的线程，则服务器/容器不知道它们，并且依赖此信息的所有功能都不再起作用。您可能会通过在您生成的线程中不使用任何这些功能来解决这个问题。

一些链接

http://www.oracle.com/technetwork/java/restrictions-142267.html#threads http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html#spring-4

如果我们检查 Servlet 3.0 规范，我们会发现:

2.3.3.3 Asynchronous processing

Java Enterprise Edition features such as Section 15.2.2, “Web Application Environment” on page 15-174 and Section 15.3.1, “Propagation of Security Identity in EJBTM Calls” on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.

这是关于异步处理，但同样的限制适用于自定义线程。

public void start(Runnable r) - This method causes the container to dispatch a thread, possibly from a managed thread pool, to run the specified Runnable. The container may propagate appropriate contextual information to the Runnable.

同样，异步处理，但同样的限制适用于自定义线程。

15.2.2  Web Application Environment

This type of servlet container should support this behavior when performed on threads created by the developer, but are not currently required to do so. Such a requirement will be added in the next version of this specification. Developers are cautioned that depending on this capability for application-created threads is not recommended, as it is non-portable.

不可移植意味着它可以在一个服务器上但不能在另一个服务器上。

如果您想在 MDB 之外使用 JMS 接收消息，您可以在 javax.jms.MessageConsumer 上使用四种方法:

• #receiveNoWait() 你可以在容器线程中对此进行处理，它不会阻塞，但它就像偷看一样。如果没有消息，它只返回 null。这不太适合收听消息。
• #receive(long) 您可以在容器线程中对此进行处理，它确实会阻塞。您通常不希望在容器线程中进行阻塞等待。同样不太适合收听消息。
• #receive()，这可能会无限期地阻塞。同样不太适合收听消息。
• #setMessageListener() 这就是你想要的，当消息到达时你会得到一个回调。但是，除非库可以连接到应用程序服务器，否则它不会是容器线程。应用服务器的 Hook 只能通过 JCA 提供给资源适配器。

所以是的，它可能会起作用，但不能保证，而且有很多东西可能会损坏。