淘宝官网首页登录电脑版,seo价格是多少,苏州微网站开发,网站开发英文术语我想回顾一下OSGI包如何解决并使用Apache Karaf进行演示。 Karaf是基于Apache Felix内核的功能齐全的OSGI容器#xff0c;并且是Apache ServiceMix集成容器的基石。 对于第一部分#xff0c;我将讨论OSGI框架如何解决捆绑包。 在第二部分中#xff0c;我将使用Apache Karaf演… 我想回顾一下OSGI包如何解决并使用Apache Karaf进行演示。 Karaf是基于Apache Felix内核的功能齐全的OSGI容器并且是Apache ServiceMix集成容器的基石。 对于第一部分我将讨论OSGI框架如何解决捆绑包。 在第二部分中我将使用Apache Karaf演示每个规则。 让我们开始吧。 捆绑包解决规则 OSGI 捆绑软件的生命周期定义了捆绑软件的可能状态和过渡。 我们将讨论捆绑包的“已解决”状态这意味着捆绑包在“安装”之后以及满足其所有必需的依赖关系时可以达到的状态。 传统的Java类加载易受运行时ClassCastException的影响在这种情况下来自两个不同类加载器的两个具有相同完全限定名称的类会混合在一起并且一个在错误的类路径空间中使用。 OSGI的主要目标之一是通过在部署时解决所有依赖关系来避免此类运行时异常因为在部署时“快速”失败的想法比尝试在运行时跟踪类加载问题更容易调试。 例如考虑一下如何在Weblogic部署中调试一些未找到的类或类强制转换异常。 OSGI解决了这个问题。 为了使分发包达到“已解决”状态必须满足其依赖关系。 想像一下这样的“快速失败”捆绑解决方案如果您使用spring应用程序并且由于缺少bean定义而无法正确连接其中一个bean那么您将在部署时而不是在有客户的时候知道这一点。调用您的代码。 OSGI遵循相同的原则。 而不是对象级的接线依赖关系我们是接线模块和类加载的依赖关系。 一个简单的解释即解决了其依赖关系的包可能是这样的如果一个包导入导入包一个特定的包则该包必须由另一个包的导出导出包提供。 如果捆绑软件A具有Import-Packageorg.apache.foo则必须部署的捆绑软件具有Export-Packageorg.apache.foo 对于每个Import-Package包声明必须有一个具有相同包的对应Export-Package 捆绑包还可以将其他属性附加到它导入或导出的包中。 如果在示例中添加了version属性该怎么办 Bundle-Name: Bundle A Import-Package: org.apache.foo;version1.2.0 这意味着捆绑软件A依赖于软件包org.apache.foo 其最低版本为1.2.0。 是的您没有看错。 尽管使用OSGI可以指定一个版本范围但是如果您不指定范围而是使用固定版本则将导致固定值的“最小值”。 如果同一软件包有更高版本则将使用更高版本 。 因此除非有相应的包B导出所需的包否则包A将无法正确解析 Bundle-Name: Bundle B Export-Package: org.apache.foo;version1.2.0 请注意反之则不然......如果捆B出口版本1.2.0则不需要捆绑到指定版本1.2.0。 它可以使用此导入并解决问题 Bundle-Name: Bundle A Import-Package: org.apache.foo 这是因为导入会声明所需的版本。 导出的版本未指定导入包必须使用的任何内容它适用于所有属性而不仅仅是版本。 Import-Package准确指示了所需的版本或属性并且必须存在具有相同属性的相应Export-Package 如果您遇到捆绑软件A导入软件包并指定两个捆绑软件提供的版本的情况会发生什么情况 Bundle-Name: Bundle A Import-Package: org.apache.foo;version1.2.0 Bundle-Name: Bundle B Export-Package: org.apache.foo;version1.2.0 Bundle-Name: Bundle C Export-Package: org.apache.foo;version1.2.0 捆绑软件A使用哪个捆绑软件 答案是这取决于首先安装了哪个捆绑包B或C。 当找到多个具有相同版本的软件包时首先安装的软件包用于满足依赖性 在解决一些捆绑包之后热部署捆绑包会使事情变得更加复杂。 如果先安装Bundle B然后尝试同时安装Bundle A和以下Bundle D该怎么办 Bundle-Name: Bundle D Export-Package: org.apache.foo;version1.3.0 从上面可以看到捆绑软件A1.2.0中的版本声明表示最低版本为1.2.0 因此如果有更高版本可用它将选择该版本本例中为Bundle D版本1.3.0。 但是这将我们带到了束分解的另一个时间性规则 已解决的捆绑包比未解决的捆绑包具有更高的优先级 原因是OSGI框架倾向于支持给定捆绑软件的可重用性。 如果已解决并且新的捆绑软件需要它那么即使不需要它也不会尝试拥有同一软件包的许多其他版本。 捆绑“使用”指令 上面关于包解析的规则仍然不够并且在运行时仍可能使用错误的类从而导致类转换异常或类似事件。 你看到什么可能会丢失吗 如果我们有这种情况怎么办。 捆绑软件A导出一个包org.apache.foo 其中包含一个类FooClass。 FooClass具有一个返回BarClass类型的对象的方法但是BarClass不在捆绑软件的类空间中定义它的导入方式如下 public class FooClass {public BarClass execute(){ ... }
} Bundle-Name: Bundle A Import-Package: org.apache.bar;version3.6.0 到目前为止只要有另一个捆绑包可以正确导出具有正确版本的org.apache.bar 一切就可以了。 Bundle-Name: Bundle B Export-Package: org.apache.bar;version3.6.0 这两个捆绑包可以解决。 现在如果我们再安装两个捆绑包捆绑包C和捆绑包D如下所示 Bundle-Name: Bundle C Import-Package: org.apache.foo;version1.2.0, org.apache.bar;version4.0.0 Bundle-Name: Bundle D Export-Package: org.apache.bar;version4.0.0 我们可以看到Bundle C从Bundle A导入了一个包org.apache.foo。Bundle C可以尝试使用org.apache.foo中的FooClass但是当它获得返回值一种BarClass类型时会发生什么 捆绑软件A希望使用BarClass的3.6.0版本但是捆绑软件C则使用的是4.0.0版本。 因此在运行时捆绑包内使用的类不一致即您可能会遇到某种类型的不匹配或类强制转换异常但是按照上述规则所有内容在部署时仍可以很好地解决。 我们需要告诉任何导入org.apache.foo的人 我们使用的是来自org.apache.bar特定版本的类如果要使用org.apache.foo 则必须使用与导入的版本相同的类。 这正是uses指令的作用。 让我们更改包A以确切地指定 Bundle-Name: Bundle A Import-Package: org.apache.bar;version3.6.0 给定捆绑软件A的新配置捆绑软件将无法从上方正确解析。 捆绑软件C无法解析因为它导入了org.apache.foo但是捆绑软件A上的“使用”约束指定C必须使用与org.apache.bar相同的版本3.6.0否则捆绑软件将尝试部署时无法解决。 解决方案是将Bundle C中org.apache.bar的版本更改为3.6.0。 使用Apache Karaf OSGI容器Karaf基于Apache Felix核心但是如果需要可以替换Equinox核心。 Karaf是功能齐全的OSGI容器并且是Apache ServiceMix集成容器的基石。 ServiceMix基本上是Karaf但专门针对Apache CamelApache ActiveMQ和Apache CXF进行了调整。 本教程将需要Maven和Karaf。 从maven网站下载maven 。 按照Karaf网站上的入门指南中的说明下载并安装karaf。 您还将需要此示例附带的代码。 您可以在我的github仓库中获得它 。 获得它之后请确保从顶级项目中运行“ mvn install”。 这将构建并将所有捆绑软件安装到本地 Maven存储库中。 尽管可以通过几种不同的方式安装捆绑软件但使用maven最为简单。 请注意此示例代码主要由没有任何实际Java类的程序包名称组成除非本教程指定。 首先要做的是启动karaf。 在普通发行版中不应安装捆绑软件。 通过在karaf命令行中执行“ osgilist”来验证这一点。 按顺序进行我们将测试上面给出的规则。 对于每个Import-Package包声明必须有一个具有相同包的对应Export-Package 为了测试此规则让我们从示例捆绑软件中安装捆绑软件A。 捆绑包A指定“ org.apache.foo”包的导入包。 根据第一个规则此捆绑包无法移至“已解决”状态因为没有对应的捆绑包具有org.apache.foo的“导出包”。 在karaf命令行中输入“ osgiinstall mvnexplore-bundle-resolution / bundleA / 1.0”。 这将安装bundleA捆绑软件。 现在再次执行“ osgilist”。 您应该看到捆绑软件已安装并且在“状态”列下应显示为“已安装”。 现在尝试“ osgiresolve bundle id ”其中bundle id是从“ osgilist”命令中列出的ID。 这将尝试解决所有捆绑软件依赖关系并将其置于“已解决”状态。 但是它无法解决。 再次键入“ osgilist”以查看捆绑软件的状态。 即使我们要求OSGI对其进行解决它仍处于“已安装”状态。 让我们找出原因。 执行“ osgiheaders 捆绑包ID ”。 在导入包下您应该看到以红色列出的包名称org.apache.foo。 缺少此依赖性因此让我们添加它。 输入“ osgiinstall -s mvnexplore-bundle-resolution / bundleB / 1.0”。 注意命令中的“ -s”开关。 这告诉OSGI一旦安装了捆绑软件就启动捆绑软件。 现在再次键入osgiresolve命令带有适当的捆绑软件ID。 现在这将解决捆绑包。 Import-Package准确指示了所需的版本或属性并且必须存在具有相同属性的相应Export-Package 让我们安装捆绑软件C“ osgiinstall -s mvnexplore-bundle-resolution / bundleC / 1.0 再次列出捆绑软件您将看到尽管捆绑软件C依赖于org.apache.foo但它指定的Import-Package的特定版本为1.5。 没有解决的1.5版因此包C也将无法解决。 捆绑软件D恰巧导出了版本等于1.5的软件包org.apache.foo。 使用-s启动捆绑软件D就像安装其他捆绑软件一样安装它。 现在尝试解析捆绑软件C它应该可以工作“ osgiresolve bundle id ”。 当找到多个具有相同版本的软件包时首先安装的软件包用于满足依赖性 该规则表示如果有多个使用相同版本导出的软件包则OSGI将在尝试解析导入软件包的软件包时选择首先安装的软件包。 继续前面的示例在该示例中我们安装了捆绑软件C和D……请考虑捆绑软件D导出org.apache.foo; version 1.5。 因此如果我们安装输出完全相同的软件包和版本的软件包F我们应该看到软件包C是用软件包D中的软件包而不是软件包F来解决的。让我们看看..安装软件包F“ osgiinstall -s mvn Explore-bundle-resolution / bundleF / 1.0?。 执行osgilist并查看捆绑软件D和F均已正确安装并处于“活动”状态。 这是OSGI的一项很酷的功能我们可以同时部署同一软件包的多个版本在此示例中包括完全相同的版本。 现在我们应该卸载捆绑软件C并重新安装它以查看它使用哪个捆绑软件来解析其org.apache.foo的导入。 尝试运行“ osgiuninstall bundle id ”以卸载捆绑软件C。现在使用上面的命令重新安装它。 它应该确定使用捆绑软件D。使用“ packageimport 捆绑软件ID ”进行验证。 您可以尝试左右切换以使F得以解决。 您可能需要使用“ osgirefresh”来刷新OSGI捆绑软件。 已解决的捆绑包比未解决的捆绑包具有更高的优先级 在某种程度上我们已经在上一条规则中看到了这一点但是在热部署时该规则会起作用。 这留给读者练习因为这篇文章已经很长了我接下来将介绍“ uses”指令。 捆绑“使用”指令 “ uses”指令添加了最后的规则和约束之一以避免运行时类广播异常。 为了模拟“ uses”指令的工作方式我们将安装捆绑软件GHI和J并注意容器如何执行“ uses”指令。 捆绑软件G代表一种“服务”模块客户端模块可以调用该服务模块以“执行”某种形式的处理并返回结果。 它返回的结果是来自捆绑软件H的BarClass类型的对象。但是如果客户端调用捆绑软件G它也必须使用捆绑软件H的BarClass否则将导致类强制转换异常。 在我们的示例中捆绑软件I是客户端代码捆绑软件J代表BarClass的不同版本。 以您喜欢的任何顺序安装软件包但我的演示遵循以下顺序JHGI。请注意即使软件包H是org.apache.bar的版本实际上也是来自软件包H的2.0.0版本。是第二次安装的与上面的规则相反。 这是因为捆绑软件G指定了“ uses”指令依赖于org.apache.bar的特定版本。 参考在Christian Posta软件博客上从我们的JCG合作伙伴 Christian Posta 了解如何解决OSGI捆绑 软件 。 翻译自: https://www.javacodegeeks.com/2012/05/understanding-how-osgi-bundles-get.html
