过去两年我在不同的任务中使用了Karaf（2.4。*和4.0。*），并且每次在卸载/安装时遇到API捆绑的缓存问题。
让我们假设以下情况：
当我使用bundle时会出现不同的行为：install -s用于安装bundle，卸载用于卸载它们：
-core并不总是停止。实际上，他使用的是service-api的缓存版本。当我进行-i（2）导入时，我甚至可以看到bundle id（1）。做一个“resolve（2）”并没有解决问题，只有“停止（2）”然后重新启动它。
当我安装service-api / 1.1.0时，3中的错误仍然存在，我的服务核心再次使用旧的-api。最大的问题是如果我安装一个新的service-soap，它将使用bundle（3），而（2）使用（1），因此它会在类加载器之间产生冲突。
我在互联网上找不到任何有关此事的资源，我尝试过Equinox＆amp; amp;菲利克斯和我没有看到任何解决该问题的方法。是捆绑：安装捆绑的好方法？使用部署是否是更好的解决方案？
Bonus：在OSGI规范中，在发布所有引用之前不应该卸载bundle，但是在Karaf中，bundle正在直接卸载它。这可能是上述问题的原因吗？
答案 0 :(得分：2)
您看到的是符合OSGi规范。当您卸载API时，所有使用它的bundle仍将使用它，直到再次解析它们为止。 引入此行为是为了避免运行时中的级联更改。
要使捆绑包获取或松散API，您需要解析捆绑包。最简单的方法是使用resolve命令。它解析了给定的捆绑包或所有捆绑包。
自动解决捆绑包的另一种方法是始终使用Apache Karaf功能安装它们。当您安装/卸载功能时，Karaf将始终确保重新解析可能受影响的所有捆绑包。
答案 1 :(得分：2)
要添加到Christian的答案 - 您需要了解安装/卸载软件包的不同方法是如何工作的。不幸的是似乎没有标准的方法！
例如，如果您从gogo shell卸载它将无法重新解析。也就是说，使用已删除的捆绑包的捆绑包仍然会表现为好像什么都没有发生，直到它们被重新解析。但是，如果您通过fileinstall安装然后卸载，它将自动重新解析。与基督徒指出的Karaf特征相同。
正如您所看到的here，您所描述的不是特定于Karaf的问题。