网站百度关键词seo排名优化,河南省住房和城乡建设厅门户网站,微信 wordpress php7,北京华诚传媒有限公司官方网站java11osgi最近#xff0c;我致力于在OSGi环境中使Apache Hive工作。 虽然没有被证明是小菜一碟#xff08;软件对吗#xff1f;。。为什么我不感到惊讶#xff1f; #xff09;#xff0c;它引导我解决了各种Java和OSGi错误。 在这里#xff0c;我列出了其中一些让我有… java11osgi 最近我致力于在OSGi环境中使Apache Hive工作。 虽然没有被证明是小菜一碟软件对吗。。为什么我不感到惊讶 它引导我解决了各种Java和OSGi错误。 在这里我列出了其中一些让我有些吃力的东西没有双关语所以我想为了自己的满意而在它们上面写一个博客。 java.lang.VerifyError 在初始化OSGi服务组件之一时我感到很讨厌。 由于违规捆绑软件处于活动状态因此无法立即识别出罪魁祸首。 从表面上看一切正常除了应该在捆绑中存在的服务组件初始化期间启动的Hive服务器未启动并正在运行的事实。 OSGi控制台中快速显示“ ls”表明服务组件处于“不满意”状态。 最后一个“ comp”显示了根本原因即VerifyError。 如果类的运行时依赖项与编译时使用的依赖项不同则可能会发生VerifyError。 例如如果方法签名在依赖关系之间更改则将导致此错误。 在已接受的答案的[1]中对此进行了很好的解释。 事实证明在两个捆绑包中暴露了一个软件包的稍有不同的版本这导致Hive捆绑包在编译环境中的版本上选择了不同的版本。 正确的OSGi版本控制是解决方案。 java.lang.IncompatibleClassChangeError 在系统中存在两个软件包的类似情况下也会出现此错误。 正如[2]清楚地解释的那样在我的案例中这样做的原因是在有冲突的软件包版本之间将接口更改为抽象类。 再次版本控制节省了一天。 java.lang.LinkageErrorxxxx中违反加载程序约束–等等…… 现在这似乎是一个著名的错误特别是在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.htmljava11osgi