自 Spring Dynamic Modules 的第一个里程碑以来，运行 OSGi 中 Web 应用程序的请求开始涌入。这可能是最受欢迎的功能之一，而且毫不奇怪，一旦 1.0 最终版发布，Web 支持就一直是 1.1 分支的主要关注点。我很高兴地报告，随着刚刚发布的 M2，正如 Juergen 已经暗示的那样，Spring-DM 不仅支持标准的 war（自 1.1.0 M1 起可用），还支持在 OSGi 中运行的 Spring-MVC 应用程序。在本文中，我想简要讨论典型的 OSGi Web 场景和 Spring-DM 的方法。但首先，

为什么要在 OSGi 中部署 WAR？

简单问题：OSGi *原生* 提供版本控制、包连接和热重加载。想象一下在您的应用程序中利用这些功能：您可以停止将库嵌入WEB-INF/lib并将它们在 Web 应用程序之间共享，避免 taglibs 重复（同时保持多个版本运行），并实时更新应用程序的特定部分。这尤其有用，因为 Web 应用程序往往是分层的，因此在其生命周期中会经历大量更改。

为什么 OSGi 中的 Web 应用程序存在问题？

Servlet 规范围绕着一个*Web 容器*的概念：一个为 Web 组件提供运行时环境的运行时环境，该环境提供标准服务，如生命周期管理（对象创建和处置、线程分配）、并发、HTTP 请求处理等。另一方面，OSGi 平台也作为具有服务注册表、包连接和版本控制（仅举几例）的托管环境。为了解决这个问题，OSGi 委员会设计了 compendium 规范的一部分，即 Http Service。

顺带一提，在处理两个托管环境时，会遇到一个有趣的问题：应该使用哪种部署模型？也就是说，哪个是引导平台，哪个是嵌入式平台。在我们的案例中，可以将 OSGi 平台部署为 WAR，或者将 Web 容器（以某种服务形式）部署到 OSGi 平台内部。更多关于这方面的内容，将在未来的博文中介绍。

这项可选服务提供了一个简单的 API，用于注册Servlet以及静态资源，这些资源会映射到传入的 HTTP 请求。为了在 OSGi 中Servlet提供服务请求，必须**以编程方式**创建Servlet实例并通过上述 API 进行注册。此外，Http 服务仅支持Servlet2.1 规范，这可能非常不方便，因为过滤器和监听器（当今几乎所有 Web 框架都使用）不可用。大多数（如果不是全部）我所知的、用于在 OSGi 中运行 Web 应用程序的解决方案，都依赖于 Http 服务来实现其功能。据我所知，其中一些解决方案通过以下一种技术来解决上述问题：

• 通过强制采用新的声明式方法或转换现有的声明式方法（例如web.xml）来调用 Http 服务，从而消除对代码的需求
• 通过在 2.1 API 之上进行构建（例如，可以通过装饰Servlet实例）或通过扩展标准 API 来提供Servlet2.1+ 功能

这两种方法都可以成功并发挥很大作用，然而，在 Spring-DM 中，我们选择了另一种独特的方法，即

直接与 Web 容器集成

在 Spring-DM 中，OSGi 和容器空间被桥接起来：WAR 包照常部署到 Web 容器，但它们使用 OSGi 空间作为类路径和资源查找。这种方法的主要优点是，对于 OSGi 平台和 Web 容器来说，都没有发生重大变化——一切都“照常运作”。

使用 Spring-DM，您可以获得

• 完整的 Servlet 2.4/2.5、JSP 2.0/2.1 规范支持
• 容器功能的可用性（阻塞与非阻塞 IO、线程池中的分配线程等）
• 完全访问web.xml语法，无论是关于过滤器、监听器、映射声明、安全还是 JNDI 引用。这在容器与 JTA 事务管理器或 JMS 队列集成的情况下尤其有用。请注意，Spring-DM 不进行解析（我们认为容器在这方面做得比我们**好得多**）
• 容器特定的配置文件（例如 Tomcat 的META-INF/context.xml)

以上所有以及更多功能之所以成为可能，是因为 Spring-DM 将 bundle **原生**部署到选定的 Web 容器（目前支持 Apache Tomcat 5.5.x/6.0.x 和 Jetty 6.1.x+）。这意味着 Web 容器负责实例化和管理 Web 应用程序，因此容器支持的几乎所有内容都可供 OSGi bundle 使用。

虽然 1.1 尚未最终确定，但我鼓励您尝试一下 M2。API 基本上已经稳定，新功能也已记录在案（随着我们接近 GA 版本，将有更多内容），如果您需要帮助，请查看 Spring-DM 论坛（是的，我们终于有了！）和邮件列表。此外，如果您恰巧参加了 JavaOne，请光临 SpringSource 展位，您将从源头获得答案。