java - org.osgi.* 的包导入是否有不同的处理方式?

标签 java osgi constraints apache-karaf ipojo

在 OSGi 中,使用版本号和版本范围时,已定义依赖项的解析过程(即包导入和导出)非常严格。如果对于版本 1.2.3 的某些包导入,未找到包含 1.2.3 范围的相应导出,则无法解析或启动该包。这很好。

但是,这似乎不适用于核心包org.osgi.framework。 Equinox (3.8.0) 和 Apache Felix (4.0.3) 的当前版本都将 org.osgi.framework,version=1.7.0 定义为导出包之一。但是一个 bundle 需要该包的特定较低版本,例如Import-Package: org.osgi.framework;version=1.3,仍然解决了这个问题到这个较新的版本。我预计该 bundle 不会得到解决。

如何解释这种行为?这是 OSGi 实现的不当行为吗?我在解析核心 OSGi 包时缺少异常吗?还是 Karaf 妨碍了这里(我用 Apache Karaf 对此进行了测试,见下文)

我知道我不想显式声明版本,并且该版本会产生一个完全可解析的范围。然而,有一些不受我控制的包定义了此类导入(即:iPOJO,见下文)。

<小时/>

一些设置细节:我在 Karaf 2.3.2 和 2.3.3 中测试了这一点,分别启用了 Equinox 或 Felix。您可以找到我用于测试的演示包 over at github ,它可以按原样构建,并且在部署到新的 Karaf 容器时会显示失败。我发现这一点的原因是因为 core iPOJO bundle定义这样的显式版本而不是范围。我将其添加到 Karaf 功能描述符中,并尝试使用 Karaf Features Maven Plugin 验证功能导出/导入完整性。 ,失败了。

最佳答案

在 OSGi 中,导入 version=1.3 相当于 version="[1.3,∞)"。请参见第 3.2.6 节“版本范围”。这是有历史原因的。

您应该始终在导入包语句中使用完整的版本范围。

关于java - org.osgi.* 的包导入是否有不同的处理方式?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19098447/

相关文章:

来自匿名内部类内部的Java返回方法

java - Hibernate Cascade DELETE OneToMany 不起作用。违反参照完整性约束

java到python的转换: x509/dsa/sha1withdsa crypto howto?

java - 错误: type org. osgi.util.tracker.ServiceTracker不接受参数

java - bndtools/osgi 中 Unresolved 要求 : Import-Package: org. apache.commons.codec.language

swift - 自调整单元格使 View 拉伸(stretch)

java - 如何在 NetBeans 中为 GridBagLayout 设置 "columnWeights"和 "rowWeights"?

ios - 多屏支持 iOS 8+

c++ - 生成具有差异约束的随机整数

Java:从 OSGi 应用程序中设置时区