设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客
LUPA开源社区 首页 业界资讯 技术文摘 查看内容

Apache Karaf基础功能

2016-11-17 21:32| 发布者: joejoe0332| 查看: 1372| 评论: 0|原作者: Robbie_Zhu, imqipan, Elven_Xu, douxingxiang|来自: oschina

摘要: 在先前的文章, 我就怎样使用Apache Karaf的“特性”以简单将OSGi包(bundle)添加到一个容器中(包括处理依赖)进行过简述。就像在文章中所讨论的那样, 就Karaf的“特性仓库”而言有自身的XML格式,它是一个列出了一 ...

先前的文章, 我就怎样使用Apache Karaf的“特性”以简单将OSGi包(bundle)添加到一个容器中(包括处理依赖)进行过简述。

就像在文章中所讨论的那样, 就Karaf的“特性仓库”而言有自身的XML格式,它是一个列出了一个或多个新特性的XML文件。其中每个特性列出了其依赖的包含版本支持的特性或包(bundle)。之所以这些能够运作,是因为Karaf可以从(包括Maven在内的)不同的源获取特性仓库的XML文件及其OSGI包。

上次我演示了一行命令从Maven中新建一个属性仓库的XML文件,然后通过命令安装了一个属性。然而,当在生产环境中使用Karaf时,我们当然需要在启动的时候使之加载合适的属性。

Karaf 性能配置

为了实现Karaf特性,我们会更新一些etc/目录下的Karaf配置文件,第一个需要更新的文件是org.apache.karaf.features.cfg。这个文件包含两个相关设置:featuresRepositoriesfeaturesBoot。

featuresRepositories的输入是一个可以被检索的URLs列表的特征库文件。正如我们上次说的,Karaf用“特征库”映射具有一个或多个特征的XML文件。这种“特征库”的XML文件可以依赖一个Web服务器上的文件系统,或(最常见)在maven仓库的文件。(在这里的名字有点重叠)。

为了使Karaf能够在启动时将Apache Camel添加到特征库的列表,我们只是增加一项列表:

featuresRepositories = \
    mvn:org.apache.karaf.features/spring/4.0.7/xml/features, \
    mvn:org.apache.karaf.features/framework/4.0.7/xml/features, \
    mvn:org.apache.karaf.features/enterprise/4.0.7/xml/features, \
    mvn:org.apache.karaf.features/standard/4.0.7/xml/features, \
    mvn:org.apache.camel.karaf/apache-camel/2.18.0/xml/features

最后一行是唯一新增的(与前一行上的反斜杠是为了其为有效的java文件)。这个Maven坐标告诉Karaf到哪找到Camel的特征库的XML文件。Karaf建立在足够的Maven支持使其能够在配置Maven库列表中找到该文件。

就其本身而言,这不会使Karaf需要另外安装任何东西;我们还需要为featuresboot添加一个或多个特征。这是一个逗号分隔的功能列表,在启动时安装;所有捆绑的功能也将启动(如果可能的话)。

寻找依赖功能

如果你看一下Karaf 的功能库的XML文件,你就会注意到它只是为绑定包列出了Maven库位置,而不是为任何依赖的功能。依赖功能只是通过名称列出来。

然而,也可以用一个功能文件为依赖的功能指定额外的功能库位置。例如,Camel功能库XML文件中的配置:

  <repository>mvn:org.apache.cxf.karaf/apache-cxf/3.1.7/xml/features</repository>
  <repository>mvn:org.apache.jclouds.karaf/jclouds-karaf/1.9.2/xml/features</repository>
  <repository>mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features</repository>

当库添加到功能库列表时,这些库会被立即添加;Karaf 不会等到功能安装时才添加。不只是这些,Karaf还会立马去取功能库的XML文件,去查找哪些功能是可用的。

潜在的混乱

随着时间的推移,我不得不使用这个不太像期望的那样友好或完整的功能库XML文件。特别是,它们只是列出来功能依赖,但没有列出查找这些功能的库。

为了解决这个问题,我们不得不在Karaf 配置中的featuresRepositories列表中增加功能库,现在,Karaf 就拥有了一个查找功能所有位置的综合列表。但是,这部分很混乱。由于它们将会做为一个依赖被拉取进来,因此也不一定要在featuresBoot中添加它们。这对新人来说是混乱的源泉,因为他们会看到在列表中的功能XML文件的位置,却没有在项目启动时启动的功能列表中看到它, 而觉得这是个问题。

配置Maven

还有一个极其重要的文件,这个文件为Karaf配置按正确的顺序查找并安装功能和捆绑包的配置:org.ops4j.pax.url.mvn.cfg。从名称就知道,这个文件配置了从OPS4J到正确的处理Maven URL的Pax URL .

Pax URL和任何安装了的Maven有一个有趣的关系。它不要求安装Apache Maven ;必要的代码已经嵌入发布的Karaf 中。但是,它默认的使用了每一个Maven用户在$HOME/.m2/settings.xml的设置文件和每一个用户在$HOME/.m2/repository的本地库

虽然每个Maven安装程序(如Maven Central)都提供了可用的Maven仓库,但是默认情况下,它并没有显式使用这些“回退(fallback)”仓库。相反,它拥有自己内建的仓库列表。然而,配置文件没有使用代码中内建的仓库列表,它只使用了配置文件中指定的仓库列表。因此,列表包括Maven Central,所以这个差别不怎么重要。但是如果更改了org.ops4j.pax.url.mvn.cfg配置文件,差别就非常重要了。

更糟的是,配置文件同时按照目录格式列出了Karaf安装位置内的仓库作为defaultRepositories,这种方式甚至覆盖了$HOME/.m2指定的本地Maven仓库。

这很容易混淆,所以总结一下:

  • Maven安装位置的全局配置文件:未使用。

  • $HOME/.m2指定的Maven settings.xml:默认。

  • Karaf分发版的默认仓库:默认;修改请慎重。

  • 内建仓库:可用,但是被配置文件覆盖。

  • org.ops4j.pax.url.mvn.cfg配置:一直使用,可以指定是否使用其他仓库。

最后,我发现,在联网环境下,可以在列表最后追加一个新仓库,这样很容易就能忽略上面那些配置;在无网环境下,我们可以用一个可用的Maven仓库替换这个列表。

虽然写了这么多,我仍然希望能用一个简单的例子,讲到编写Karaf特性仓库XML文件的一些最佳实践。



酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部