代码之家 › 专栏 › 技术社区 › jcalvert

如何部署OSGi应用程序和依赖项?

dependency-management osgi maven-2 java

jcalvert · 技术社区 · 15 年前

OSGi似乎有一个很好的好处,即不将几十个JAR依赖项包装到lib目录中,从而拥有小型的可部署构件。但是,我找不到任何东西告诉我一种简单、可靠的方法来将依赖项部署到容器。例如,我有一个使用CXF和几个Spring子项目的应用程序。如果我需要将这个应用程序部署到一个新的Glassfish服务器上,那么确保安装所有依赖项的最佳方法是什么?

似乎可能有某种方法可以让钩子查看META-INF/maven目录,从pom.xml中提取依赖项列表,并获取所需的lib(可能是从本地repo中)。有办法吗?

Pax插件听起来像是这样做的,但它似乎是基于隆胸一个Felix容器?这不是我想要的,我正在处理一个已经运行的远程容器。

3 回复 | 直到 15 年前

Derek Baum 15 年前

有很多方法可以将依赖的bundle部署到OSGi容器中。以下是其中一些:

1 Felix OBR束库

首先需要使用bindex等工具为可用的包创建一个XML索引文件。如果您使用的是maven bundle插件,那么它会自动在~/.m2/repository/repository.xml中维护OBR索引。

> obr:addUrl file:/Users/derek/.m2/repository/repository.xml

然后让OBR部署目标包,依赖项由OBR索引确定:

> obr:deploy com.paremus.posh.sshd
Target resource(s):
-------------------
   Paremus Posh Ssh Daemon (1.0.23.SNAPSHOT)

Required resource(s):
---------------------
   Paremus Command API (1.0.23.SNAPSHOT)

Optional resource(s):
---------------------
   Paremus Config Admin Commands (1.0.23.SNAPSHOT)
   Paremus OSGi & LDAP Types (1.0.23.SNAPSHOT)

Karaf支持“特性”,基本上是提供特性所需的捆绑包列表:

karaf@root> features:info obr
Description of obr 2.0.0 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no dependencies.
Feature contains followed bundles:
  mvn:org.apache.felix/org.apache.felix.bundlerepository/1.6.4
  mvn:org.apache.karaf.shell/org.apache.karaf.shell.obr/2.0.0
  mvn:org.apache.karaf.features/org.apache.karaf.features.obr/2.0.0

karaf@root> features:install obr

3日食处女座

处女座使用计划定义组成应用程序的工件,并且它能够从本地和远程存储库自动提供应用程序的依赖项,包括包、计划、计划存档(PAR)和配置。

4灵巧的帕雷姆斯

Nimble还可以配置为启动Glassfish,以便其功能可用于Glassfish容器中的捆绑包。

$ posh
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
[denzil.0]% nim:add --dry-run com.paremus.posh.sshd@active
-- sorted parts to install --
4325   osgi.resolved.bundle/ch.qos.logback.core:0.9.22
-- start dependency loop --
5729   osgi.resolved.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
5727   osgi.active.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
3797   osgi.resolved.bundle/ch.qos.logback.classic:0.9.25.SNAPSHOT
3792   osgi.resolved.bundle/slf4j.api:1.6
-- end dependency loop --
436   osgi.resolved.bundle/org.apache.mina.core:2.0.0.RC1
6533   osgi.resolved.bundle/sshd-core:0.3
398   osgi.resolved.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
396   osgi.active.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT

(免责声明:我是Paremus的开发人员)

5阿帕奇·费利克斯·戈戈

gogo是新的RFC147标准命令行shell。它已经被用于费利克斯,卡拉夫,灵巧,很快将可用于玻璃鱼。

Gogo允许您运行任何可以交互输入的命令,作为脚本。因此,您可以生成要安装的bundle列表并将其转换为脚本,甚至可以从工作配置捕获已安装的bundle,以便从一个干净的开始重新创建它。

SteveD 15 年前

如果您创建一个OSGi应用程序和一个经典的Java应用程序,它们做同样的事情并使用相同的库,那么您将需要完全相同的jar集。最大的区别在于能够显式地定义依赖项(并可能为应用程序生成更细粒度的jar)。

我只知道一个纯粹基于OSGi的服务器(Eclipse的Virgo,以前是Spring的DM服务器)。Glassfish和Websphere支持OSGi,但我还没有使用它们,所以我不能说太多。我能说的是,它们都需要一个OSGi容器,通常是Eclipse的Equinox或Apache的Felix。

您的问题似乎真的是关于配置应用程序(确定需要部署什么)。我知道对于Maven 3.0,他们已经用Eclipse的P2供应框架做了很多工作。

对于您的应用程序,您是部署EAR还是部署WAR?对于这两种情况中的任何一种,您的构建系统都需要生成具有所有依赖项的存档,否则将无法工作。人们之所以使用Maven,是因为它为他们的构建执行可传递的依赖管理,这让人有点困惑。

-1

Bernard Hauzeur 8 年前

你的问题有一个根本的方面尚未解决。

Glassfish确实是一个成熟的应用服务器,与大多数现代应用服务器一样:它们为您提供了 Web容器 (部署战争档案的地方),一个 Java EE容器 (部署EJB在JAR和EAR中的存档),以及集成 OSGI容器

实质上,你可以瞄准 三个集装箱 如何利用所有这些可能性构建应用程序?

有几个非常重要的 技术的 不可忽视的问题。(我在这里着重于客观和事实的考虑,不涉及任何主观的选择、哲学、战略和其他可能对你的最终决定有很大影响的与背景相关的考虑):

OSGI容器不能为您提供 隐式或声明式 线程管理 , 坚持不懈 ,或像Web和Java EE容器这样的服务。所以,一定要计划分析这些问题,并生成代码来管理您的线程,例如处理这些线程上的事务传播。当然,OSGi提供了所有必要的api来处理这些方面,但确实需要编码(AOP可能会有帮助)。另一方面,在Web和Java EE容器中,您依赖于容器管理的服务和/或使用EJB注释、部署描述符和服务器管理的对象(如池)来简单地声明您希望并行的线程数量、连接池的大小以及哪些事务属性。两种风格都有优缺点(OSGi中的过程式与java应用中的声明式或隐式)。服务器)。
OSGI提供了 有秩序的 加载你的代码,管理 模块依赖项 ,甚至处理多个 共存版本 同一模块的,以及所谓的捆 (OSGI部署单元),前提是您的包确实包含处理潜在启动/停止问题的逻辑,例如在一个停止上正确中断所有启动的线程——这些线程可能已经通过其他依赖模块“传播”了。另一方面,Java EE和Web容器通常会装载依赖JAR的副本,除非您开始考虑应用服务器的 类加载器层次结构 并利用它将“共享库”部署为普通的POJO JAR或打包在JAR中的Java EE bean 构建时间 使用像Maven这样的框架。然后,在运行时,您可能必须根据依赖关系编写启动/停止级联脚本;否则,请利用解决这些问题的特定应用程序服务器扩展 动态部署 Web和Java e e容器中的问题(例如Weblogic)。
如前所述,OSGI现在被大多数应用服务器用来管理它们自己的 启动顺序 . 随着平台的日益复杂,API的成倍增长,开发团队组装单个最终产品的数量增加,以及大量第三方/开源组件的使用,OSGI成为不可或缺的以确保所有组件的稳定版本和一致的兼容版本集。想想EclipseIDE:有成千上万的插件和高速度的新版本,如果没有OSGI作为基础,这个IDE将是一个非常脆弱的平台。现代应用服务器也面临同样的问题。
基于以上考虑 ,你可能很想层 (a) 如何使所有这些组件相互通信? OSGI有自己的存储库机制,除非在OSGI中显式发布,否则其他模块将看不到部署的JAR的API。Web和Java EE容器使用完全不同的存储库技术来访问其他组件的接口,即JNDI。再次,请查看您的特定应用服务器文档,这些文档可能提供了从OSGI捆绑包处理Java EE bean的方法,反之亦然(例如,Glassfish,自V3以来);但是要小心线程管理和事务作用域。 (b) 如何避免干扰应用服务器的启动顺序? 自然地

问题很丰富,分析也很复杂。进一步的考虑必须考虑到要构建的应用程序的性质。此外,如果您打算使用开源Spring和/或Camel等开发框架,以及Oracle Fusion SOA composites、JBoss Switchyard等特定于供应商的框架,那么您还需要考虑许多其他的技术约束。

在这些问题上,没有“一刀切”的答案,而这在本质上证明了当前大量重叠技术的合理性。