我最近一直在研究OSGi，认为对于模块化Java应用程序来说，这似乎是一个非常不错的主意。

但是，我想知道OSGi如何在Web应用程序中工作，在那里我们不仅仅需要担心HTML，图像，CSS之类的代码。

在工作中，我们正在构建一个具有多个"标签"的应用程序，每个标签都是应用程序的一部分。我认为这可以从采用OSGi的方法中真正受益，但是我真的不确定什么是处理所有常规Web应用程序资源的最佳方法。

我不确定是否有任何区别，但是我们正在使用JSF和IceFaces(这又增加了另一层问题，因为我们具有导航规则，并且必须在web.xml中指定所有face config文件...哎呀！ )

编辑：根据此线程，可以从JAR文件中加载faces-config.xml文件，因此，如果我们分成了JAR文件，则实际上可以包含多个faces-config.xml文件而无需修改web.xml。

任何建议将不胜感激 ：-)

解决方案

我们非常认为这里有协同作用，我们有一个模块化的Web应用程序，该应用程序本身是由独立组件(OSGi捆绑软件)自动组装而成的，每个捆绑软件都贡献自己的页面，资源，css和可选的javascript。

我们不使用JSF(此处为Spring MVC)，因此我无法评论在OSGi上下文中该框架增加的复杂性。

那里的大多数框架或者方法仍然遵循"旧的"思维方式：一个代表Web应用程序的WAR文件，然后是许多OSGi捆绑软件和服务，但几乎没有人关心GUI本身的模块化。

设计准备工作

使用OSGi，要解决的第一个问题是：部署方案是什么，谁是主要容器？我的意思是，我们可以在OSGi运行时上部署应用程序，并使用其基础结构进行所有操作。或者，我们可以将OSGi运行时嵌入到传统的应用服务器中，然后需要重新使用某些基础结构，特别是要使用AppServer的servlet引擎。

当前，我们的设计基于OSGi作为容器，我们使用OSGi提供的HTTPService作为我们的servlet容器。我们正在寻求在外部servlet容器和OSGi HTTPService之间提供某种透明的桥梁，但是这项工作仍在进行中。

Spring MVC + OSGi模块化Webapp的架构图

因此，目标不仅是通过OSGi服务Web应用程序，而且还将OSGi的组件模型应用于Web UI本身，以使其可组合，可重用，动态。

这些是系统中的组件：

• 1个中央软件包，负责将Spring MVC与OSGi桥接，特别是它使用Bernd Kolb的代码允许我们将OSGi中的Spring DispatcherServlet注册为Servlet。
• 1个自定义URL映射器，该自定义URL映射器被注入DispatcherServlet中，并提供传入HTTP请求到正确控制器的映射。
• 1个基于Sitemesh的中央装饰器JSP，用于定义站点的全局布局，以及我们要提供的默认CSS和Javascript中央库。
• 每个要向我们的Web UI贡献页面的包都必须发布1个或者多个Controller作为OSGi服务，并确保向OSGi HTTPService注册其自己的servlet和其自己的资源(CSS，JSP，图像等)。注册使用HTTPService完成，主要方法为：httpService.registerResources()和httpService.registerServlet()

当Web ui贡献捆绑包激活并发布其控制器时，它们将由我们的中央Web ui捆绑包自动拾取，并且上述自定义URL映射器将收集这些Controller服务并保持URL到Controller实例的最新映射。

然后，当针对某个URL的HTTP请求进入时，它将找到关联的控制器，并将请求分派到该控制器。

Controller开展业务，然后返回所有应呈现的数据和视图名称(在本例中为JSP)。此JSP位于Controller的捆绑包中，并且可以由中央Web ui捆绑包访问和呈现此JSP，这恰恰是因为我们向HTTPService注册了资源位置。然后，我们的中央视图解析器将此JSP与我们的中央Sitemesh装饰器合并，并将生成的HTML吐出到客户端。

众所周知，这是一个很高的层次，但是如果没有提供完整的实现，则很难完全解释。

我们对此的主要学习点是看Bernd Kolb在他的示例JPetstore转换为OSGi方面所做的工作，并使用该信息设计我们自己的体系结构。

恕我直言，目前有太多的炒作，并且专注于以某种方式将OSGi嵌入传统的基于Java EE的应用程序中，而很少有人考虑将其实际使用OSGi惯用法及其出色的组件模型来真正允许设计组件化Web应用程序。

我们一直在将Restlet与OSGi结合使用，以通过嵌入式Http服务获得良好的效果(在幕后实际上是Jetty，但也可以使用tomcat)。

Restlet具有零到最低的XML配置需求，我们所做的任何配置都在BundleActivator中(注册新服务)。

在构建页面时，我们只处理相关的服务实现以生成输出装饰器样式。插入新的捆绑包将在下一次呈现时添加新的页面装饰/小部件。

REST为我们提供了简洁，有意义的URL，具有相同数据的多种表示形式，并且似乎具有可扩展的隐喻(少量动词，许多名词)。

对我们来说，一个额外的功能是对缓存的广泛支持，特别是ETag。

看看RAP！ http://www.eclipse.org/rap/

看一下简单易学的http://www.ztemplates.org。这使我们可以将所有相关模板，javascript和css放入一个jar中，并透明地使用它。意味着使用框架提供的组件时，我们甚至不必担心在页面中声明所需的JavaScript。

查看SpringSource dm Server，这是一个完全基于OSGi构建并支持模块化Web应用程序的应用程序服务器。它提供免费，开源和商业版本。

我们可以首先部署一个标准的WAR文件，然后将应用程序逐步分解成OSGi模块，或者说成OSGi语言的"捆绑"。就像我们对SpringSource的期望一样，该服务器对Spring框架和相关的Spring产品组合产品提供了出色的支持。

免责声明：我正在研究此产品。

有趣的帖子集。我有一个基于每个客户定制的Web应用程序。每个客户都有一套核心组件和其他组件，这取决于他们所签署的内容。对于每个发行版，我们都必须根据客户"组装"正确的服务集并应用正确的菜单配置(我们使用struts菜单)，至少可以这样说很乏味。基本上是相同的代码库，但我们只是自定义导航以显示或者隐藏某些页面。这显然不是理想的，我们希望利用OSGi来对服务进行组件化。虽然我可以看到如何针对服务API进行此操作，并且可以了解如何将CSS和Java脚本以及控制器(我们使用Spring MVC)之类的资源也进行捆绑，但是我们将如何处理诸如页面导航之类的"交叉"问题和一般的工作流程，尤其是在我们要动态部署新服务并需要向该服务添加导航的情况下。可能还存在其他"交叉"问题，例如跨其他服务的服务。
谢谢，
Declan。

请注意Spring DM服务器许可。

SpringSource似乎正在开发一个有趣的模块化Web框架，该框架基于OSGi构建，称为SpringSource Slices。可以在以下博客文章中找到更多信息：

• 带有SpringSource Slices的模块化Web应用程序
• 使用SpringSource Slices的可插拔样式
• 切片菜单栏截屏