osgi - 在OSGI中的码头部署Webapp

Question

在发布此问题之前，我已经搜索了很长时间，但没有找到满意的答案，因为前提是我想说我宁愿不使用框架来完成以下任务，我仅有的工具是Felix，Jetty和Webapp。

我有一个用maven管理的webapp，我将它部署在OSGI env之外的码头上，但是现在我也想将其部署在OSGI中，因此我要面对典型的OSGI问题和原则，请遵循我的理解，请让我知道我是否会出错：


我可以离开行家的“战争”包装
使用apache.felix maven-bundle-plugin创建OSGI清单
在OSGI中，应该在任何“ webapp捆绑包”之前启动码头捆绑
该webapp捆绑包将具有其WEB-INF /类，但实际上，它是OSGI风格，因此它没有任何WEB-INF / lib，因为它将找到与OSGI相关的依赖关系
捆绑在其他地方

如果您要添加元素，我表示感谢，很遗憾，我只找到了一些文章来快速地将标准战争捆绑在一起，但是我真的很想在OSGI原则方面开展工作，因此我希望尽可能地合规

Answer 1

首先，要回答您的高级OSGi问题：



我可以离开行家的“战争”包装



是的，但这意味着您将按照以下所有规则生成一个WAR文件。因此，您可能会在某个时候与maven-war-plugin战斗。



使用apache.felix maven-bundle-plugin创建OSGI清单



我更喜欢使用bnd-maven-plugin，但是两者都使用相同的库（bnd）。生成OSGi清单（而不是手工编写）是迈向成功的非常重要的一步。



在OSGI中，应该在任何“ webapp捆绑包”之前启动码头捆绑



在编写良好的OSGi系统中，绝对应该没有启动顺序的限制。在Jetty启动之前，您的Web应用程序将不可用，但是首先启动哪个捆绑包无关紧要。


该webapp捆绑包将具有其WEB-INF /类，但实际上，它是OSGI风格，因此将不具有任何WEB-INF / lib，因为它将在其他地方像OSGI捆绑包一样找到其依赖项。


这取决于你。显然，要保留有效的WAR文件，这些类必须位于WEB-INF / classes中。 OSGi可以解决此问题（尽管您需要设置Bundle-Classpath），但这不是必需的。如果要将它们放在/中，请继续。嵌入式JAR也受OSGi支持，但同样，不是必需的。使用/作为类路径并使用Import-Package引用库是OSGi的惯用用法。

OSGi中的Servlet

有一个支持Web应用程序的OSGi规范。它称为Web应用程序规范，它是OSGi汇编规范的第128章。这是从OSGi容器内部发布servlet的方法之一。但是，还有其他方法可以在OSGi中使用Servlet。

如果您只想使用WAR文件进行所有操作，请跳过，因为我将告诉您一个替代方案，您可能会发现它更容易/更好。

如何在OSGi中部署Servlet

在OSGi中部署servlet的最佳和最简单的方法是使用Http Whiteboard（OSGi汇编第140章）。注册servlet非常简单，您只需将其发布为OSGi服务并附带其应匹配的模式即可。例如，当使用声明式服务时：

@Component(property="osgi.http.whiteboard.servlet.pattern=/foo")
public class MyServlet extends HttpServlet implements Servlet {
    ...
}

您还可以注册过滤器，侦听器和各种其他东西。这样使用声明式服务可以很容易地通过注入其他OSGi捆绑软件提供的服务来与它们进行交互。

Apache Felix Http Service是基于Jetty的该规范的很好用的易于使用的实现。

如何部署Web应用程序捆绑包

如果您确实想作为Web应用程序捆绑包进行部署，那么需要注意一些事项。

根据原始提交者的要求进行编辑


您所有servlet的生命周期与捆绑软件的生命周期完全相同，因此很难正确使用OSGi服务。如果缺少它依赖的服务或该服务不可用，则在Web应用程序捆绑包内您将无权限制Servlet的可见性。这可能导致您依赖捆绑包启动顺序，这太糟了！
您必须在OSGi清单中设置额外的元数据，以确保OSGi可以应付WAR布局，并识别要处理的包。


Bundle-ClassPath：WEB-INF / classes [，WEB-INF / lib / foo.jar]
Web-ContextPath：

就我所知，Jetty不是OSGi Web应用程序规范的实现。您将需要一个实现（可以在Jetty之上运行），例如PAX-Web。
OSGi Web应用程序规范仅定义了对Servlet 2.5的支持（实现附加值更高）。
许多人将Web应用程序捆绑包视为迁移路径，而不是最终目标。具有特殊的内部布局（ WEB-INF/classes）并通常遵循“胖子”模型意味着Web应用程序捆绑包通常具有有限的模块化，并且可能难以与其他工具一起使用。而且，它们无法与OSGi服务良好交互（请参见第1点），这使其比OSGi Http Service白板等更多的模块化模式更难编写/维护。这意味着某些人（包括我自己）将Web应用程序捆绑包视为迁移到OSGi的“第一步”，最终使用Http Service Whiteboard。


根据您建立Maven构建的方式，您可能会发现有必要对bnd使用 -wab指令。这将使您的课程进入 WEB-INF/classes并设置 Bundle-ClassPath