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