Deployment

    Spring WebSocket API 很容易集成到 Spring MVC 应用程序中，其中 DispatcherServlet 同时服务于 HTTP WebSocket 握手和其他 HTTP 请求。通过调用 WebSocketHttpRequestHandler，它也很容易集成到其他 HTTP 处理场景中。这很方便，也很容易理解。然而，对于 JSR-356 运行时来说，有一些特殊的考虑。

    Java WebSocket API（JSR-356）提供了两种部署机制。第一个机制涉及到启动时的 Servlet 容器 classpath 扫描（Servlet 3 的一个特性）。另一种是在 Servlet 容器初始化时使用的注册 API。这两种机制都不可能为所有的 HTTP 处理 — 包括 WebSocket 握手和所有其他 HTTP 请求 — 使用单一的 前控制器（front controller），比如 Spring MVC 的 DispatcherServlet。

    这是 JSR-356 的一个重要限制，Spring 的 WebSocket 支持通过特定于服务器的 RequestUpgradeStrategy 实现来解决，即使在 JSR-356 运行时中运行。目前 Tomcat、Jetty、GlassFish、WebLogic、WebSphere 和 Undertow（以及 WildFly）都存在这样的策略。

    :::info 为克服 Java WebSocket API 中的前述限制，已经创建了一个请求，可以在 eclipse-ee4j/websocket-api#211 上关注。Tomcat、Undertow 和 WebSphere 提供了自己的 API 替代方案，使之成为可能，而且 Jetty 也可以做到这一点。我们希望更多的服务器也能这样做。 :::

    次要的考虑是，支持 JSR-356 的 Servlet 容器预计将执行 ServletContainerInitializer（SCI）扫描，这可能会降低应用程序的启动速度 — 在某些情况下，会大大降低。如果在升级到支持 JSR-356 的 Servlet 容器版本后观察到明显的影响，应该可以通过使用 web.xml 中的 <absolute-ordering />元素来有选择地启用或禁用 Web 片段（和 SCI 扫描），正如下面的例子所示：

    1. <web-app xmlns="http://java.sun.com/xml/ns/javaee"
    2.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    3.     xsi:schemaLocation="
    4.         http://java.sun.com/xml/ns/javaee
    5.         https://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    6.     version="3.0">
    8.     <absolute-ordering/>
    10. </web-app>

    然后你可以按名称有选择地启用网络片段，比如 Spring 自己的 SpringServletContainerInitializer，它提供了对 Servlet 3 Java 初始化 API 的支持。下面的例子展示了如何做到这一点：

    1. <web-app xmlns="http://java.sun.com/xml/ns/javaee"
    2.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    3.     xsi:schemaLocation="
    4.         http://java.sun.com/xml/ns/javaee
    5.         https://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    6.     version="3.0">
    8.     <absolute-ordering>
    9.         <name>spring_web</name>
    10.     </absolute-ordering>
    12. </web-app>