我最近一直在研究OSGi，并认为它对于模块化 Java 应用程序来说是一个非常好的主意。
但是，我想知道 OSGi 将如何在 Web 应用程序中工作，您不仅需要担心代码——还有 HTML、图像、CSS 之类的东西。
在工作中，我们正在构建一个具有多个“选项卡”的应用程序，每个选项卡都是应用程序的一部分。我认为这可以从采用 OSGi 方法中真正受益——但是我真的不确定处理所有常用 Web 应用程序资源的最佳方法是什么。
我不确定它是否有任何区别，但我们正在使用 JSF 和IceFaces（这增加了另一层问题，因为您有导航规则，并且您必须在 web.xml 中指定所有面孔配置文件...... doh！ )
编辑：根据这个线程，可以从 JAR 文件中加载 faces-config.xml 文件 - 所以实际上可以在不修改 web.xml 的情况下包含多个 faces-config.xml 文件，前提是您将其拆分为 JAR 文件。
任何建议将不胜感激 ：-）
您认为这里有协同作用是非常正确的，我们有一个模块化的 Web 应用程序，其中应用程序本身由独立组件（OSGi 包）自动组装，其中每个包都贡献自己的页面、资源、css 和可选的 javascript。
我们不使用 JSF（此处为 Spring MVC），因此我无法评论该框架在 OSGi 上下文中增加的复杂性。
大多数框架或方法仍然坚持“旧”的思维方式：一个 WAR 文件代表您的 webapp，然后是许多 OSGi 包和服务，但几乎没有人关心 GUI 本身的模块化。
使用 OSGi，首先要解决的问题是：您的部署场景是什么？谁是主容器？我的意思是，您可以在 OSGi 运行时上部署您的应用程序，并将其基础设施用于一切。或者，您可以在传统的应用服务器中嵌入 OSGi 运行时，然后您将需要重用一些基础设施，特别是您想使用 AppServer 的 servlet 引擎。
我们的设计目前基于 OSGi 作为容器，我们使用 OSGi 提供的 HTTPService 作为我们的 servlet 容器。我们正在研究在外部 servlet 容器和 OSGi HTTPService 之间提供某种透明的桥梁，但这项工作正在进行中。
因此，我们的目标不仅仅是通过 OSGi 为 Web 应用程序提供服务，还要将 OSGi 的组件模型应用于 Web UI 本身，使其可组合、可重用和动态。
这些是系统中的组件：
每个想要为我们的 Web UI 贡献页面的包都必须发布 1 个或多个控制器作为 OSGi 服务，并确保向OSGi HTTPService注册自己的 servlet 和自己的资源（CSS、JSP、图像等）。注册是通过 HTTPService 完成的，关键方法是：
httpService.registerResources() 和 httpService.registerServlet()
当一个 web ui 贡献包激活并发布它的控制器时，它们会被我们的中央 web ui 包自动拾取，并且前面提到的自定义 URL 映射器收集这些控制器服务并保持到控制器实例的 URL 的最新映射。
然后，当某个 URL 的 HTTP 请求进入时，它会找到关联的控制器并在那里分派请求。
控制器执行它的业务，然后返回任何应该呈现的数据和视图的名称（在我们的例子中是一个 JSP）。这个 JSP 位于 Controller 的 bundle 中，并且可以被中央 web ui bundle 访问和呈现，因为我们已经使用 HTTPService 注册了资源位置。然后，我们的中央视图解析器将此 JSP 与我们的中央 Sitemesh 装饰器合并，并将生成的 HTML 输出给客户端。
知道这是相当高的水平，但如果不提供完整的实现，很难完全解释。
我们的关键学习点是查看Bernd Kolb 对他的示例 JPetstore 转换为 OSGi 所做的工作，并使用该信息来设计我们自己的架构。
恕我直言，目前有太多的炒作和专注于让 OSGi 以某种方式嵌入到传统的基于 Java EE 的应用程序中，而很少考虑实际利用 OSGi 惯用语及其出色的组件模型来真正允许组件化 Web 应用程序的设计。
查看SpringSource dm Server - 一个完全根据 OSGi 构建并支持模块化 Web 应用程序的应用程序服务器。它提供免费、开源和商业版本。
您可以从部署标准 WAR 文件开始，然后逐渐将您的应用程序分解为 OSGi 模块，或 OSGi 中的“捆绑包”。正如您对 SpringSource 所期望的那样，该服务器对 Spring 框架和相关的 Spring 组合产品具有出色的支持。
免责声明：我在这个产品上工作。
请注意 Spring DM 服务器许可。
我们一直在使用带有 OSGi 的Restlet，通过嵌入式 Http 服务取得了良好的效果（实际上它是 Jetty，但也可以使用 tomcat）。
Restlet 有零到最小的 XML 配置需求，我们所做的任何配置都在 BundleActivator 中（注册新服务）。
在构建页面时，我们只是处理相关的服务实现以生成输出，装饰器样式。插入的新包将在下次呈现时添加新的页面装饰/小部件。
REST 为我们提供了干净且有意义的 URL，相同数据的多种表示形式，并且似乎是一个可扩展的隐喻（动词很少，名词很多）。
对我们来说，一个额外的功能是对缓存的广泛支持，特别是 ETag。
SpringSource 似乎正在开发一个有趣的模块化 Web 框架，该框架构建在 OSGi 之上，称为SpringSource Slices。更多信息可以在以下博客文章中找到：
看看http://www.ztemplates.org，它简单易学。这个允许您将所有相关的模板、javascript 和 css 放入一个 jar 中并透明地使用它。意味着您甚至不必关心在使用提供的组件时在页面中声明所需的 javascript，因为框架会为您完成。
一组有趣的帖子。我有一个基于每个客户定制的 Web 应用程序。每个客户都会获得一组核心组件和附加组件，具体取决于他们注册的内容。对于每个版本，我们必须根据客户“组装”正确的服务集并应用正确的菜单配置（我们使用 struts 菜单），这至少可以说是乏味的。基本上它的代码库相同，但我们只是自定义导航以显示或隐藏某些页面。这显然不理想，我们想利用 OSGi 来组件化服务。虽然我可以看到这是如何为服务 API 完成的，并且有点理解 CSS 和 java 脚本和控制器（我们使用 Spring MVC）等资源如何也可以捆绑在一起，但您将如何处理“横切” 页面导航和一般工作流程等问题，尤其是在您想要动态部署新服务并需要向该服务添加导航的情况下。还可能存在其他“跨领域”问题，例如跨越其他服务的服务。谢谢，德克兰。