java11+osgi_错误学习：Java + OSGi

java11+osgi

最近，我致力于在OSGi环境中使Apache Hive工作。 虽然没有被证明是小菜一碟（软件对吗。为什么我不感到惊讶

java.lang.VerifyError

在初始化OSGi服务组件之一时，我感到很讨厌。 由于违规捆绑软件处于活动状态，因此无法立即识别出罪魁祸首。 从表面上看，一切正常，除了应该在捆绑中存在的服务组件初始化期间启动的Hive服务器未启动并正在运行的事实。 OSGi控制台中快速显示“ ls”，表明服务组件处于“不满意”状态。 最后，一个“ comp”显示了根本原因，即VerifyError。

如果类的运行时依赖项与编译时使用的依赖项不同，则可能会发生VerifyError。 例如，如果方法签名在依赖关系之间更改，则将导致此错误。 在已接受的答案的[1]中对此进行了很好的解释。 事实证明，在两个捆绑包中暴露了一个软件包的稍有不同的版本，这导致Hive捆绑包在编译环境中的版本上选择了不同的版本。 正确的OSGi版本控制是解决方案。

java.lang.IncompatibleClassChangeError

在系统中存在两个软件包的类似情况下，也会出现此错误。 正如[2]清楚地解释的那样，在我的案例中，这样做的原因是在有冲突的软件包版本之间将接口更改为抽象类。 再次，版本控制节省了一天。

java.lang.LinkageError：xxxx中违反加载程序约束–等等……

现在，这似乎是一个著名的错误，特别是在OSGi环境中。 根本原因似乎是由不同的ClassLoader加载的两个类，它们以某种方式进入联系。 例如，说A类对象接受B类对象作为方法参数。 B类由ClassLoader-A加载，该类加载器也加载A类。但是，在方法调用时，由ClassLoader-B加载的B类对象如何作为参数传递给已加载的A类对象通过ClassLoader-A。 现在，结果将是一个很大的LinkageError，并带有非常冗长的错误消息。

OSGi中基于图的类加载结构使其特别有利于此类错误。 在我的案例中，罪魁祸首是一个包装，该包装已被复制到两个不同的包中，并且该包中的一个特定类由每个包的单独的ClassLoader加载，并通过方法调用期间系统中存在的第三个包来联系。 因此，这是在OSGi中不遵循“导入导出内容”的最佳做法[3]的情况。 这样做将有助于减少重复的包在包中的暴露，并有助于为给定的包维护一致的类空间。 因此，这就是这种情况下的解决方案。

包使用冲突：导入包：yyy; 版本=“ xxx”

在锻炼过程中，我经常不时地面对这种不便之处。 在SpringSource上有两个关于此问题的出色文章[4]，[5]，它们提供了很多帮助。 但是，让我总结一下我在这个问题上的学习。 简单来说，如果捆绑包通过直接导入并通过使用约束暴露给同一软件包的两个版本，则会出现此错误。 该图最能说明这种情况。

捆绑软件A直接导入org.foo版本1.0.0。 但是，它也从捆绑软件B导入捆绑软件org.bar。但是事实证明，软件包org.bar也使用org.foo软件包，尽管它是与捆绑软件A导入的版本不同的版本（2.0.0）。现在捆绑软件A直接连接到org.foo的1.0.0版本，并且由于导入了使用org.foo的2.0.0版本的org.bar而暴露于org.foo的2.0.0版本。 现在，由于无法将捆绑包连接到同一软件包的不同版本，因此使用冲突将导致冒犯进口org.bar的根本原因。 （例如：程序包使用冲突：导入程序包：org.bar；版本=“ 0.0.0）。 解决方案是更改捆绑软件A或捆绑软件B中的org.bar软件包导入版本，以便它们都指向相同的软件包版本。 尼尔·巴特利特（Neil Bartlett）撰写的另一篇很棒的博客可以在[6]中找到。

java.lang.UnsatisfiedLinkError

我的一个工作朋友在尝试将另一个第三方库纳入我们的OSGi环境时遇到了这个问题。 JavaDocs继续说这变得“如果Java虚拟机无法找到声明为native的方法的适当的本机语言定义，则会抛出该错误”。 有问题的库是一个Linux .so（动态链接库）文件，在运行时捆绑ClassLoader时看不到该文件。 通过将库资源直接包含在捆绑软件ClassLoader中，我们能够使其工作。 之前在TCCL（线程上下文类加载器）上设置此资源的尝试失败了，这使我们意识到TCCL通常不是捆绑软件类加载器。 在Equinox OSGi环境下可以很好地阅读TCCL，请参见[7]。

[1] http://stackoverflow.com/questions/100107/reasons-of-getting-a-java-lang-verifyerror
[2] http://stackoverflow.com/questions/1980452/what-c??auses-java-lang-incompatibleclasschangeerror
[3] http://blog.osgi.org/2007/04/importance-of-exporting-nd-importing.html [4] http://blog.springsource.org/2008/10/20/understanding-the-osgi-uses-directive/ [5] http://blog.springsource.org/2008/11/22/diagnosing-osgi-uses-conflicts/ [6] http://njbartlett.name/2011/02/09/uses-constraints.html [7] http://wiki.eclipse.org/Context 类 Loader_Enhancements

参考： 错误学习：来自Source Open博客的JCG合作伙伴 Buddhika Chamith的Java + OSGi 。

翻译自: https://www.javacodegeeks.com/2012/05/learn-by-errors-java-osgi.html

java11+osgi

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91322 人正在系统学习中 相关资源：TranslationLoaderBundle:具有数据库翻译加载器的Symfony2捆绑软件

来源：dnc8371