），它引导我解决了各种Java和OSGi错误。 在这里，我列出了其中一些让我有些吃力的东西（没有双关语），所以我想为了自己的满意而在它们上面写一个博客。 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）。直接连接到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-causes-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
