如何查看为什么 Apache Felix Log 中未满足捆绑要求？答案

【问题标题】：How to see why bundle requirements are not fulfilled in Apache Felix Log?如何查看为什么 Apache Felix Log 中未满足捆绑要求？
【发布时间】：2016-12-12 00:29:22
【问题描述】：

我在嵌入式模式下使用 Felix，带有文件安装捆绑包，并且有一个已安装但未解决的捆绑包（因此不是启动/活动），而且我的努力比我想象的要多日志中的根本原因...

您如何/从哪里获得那些看起来很有帮助的“无法解决......因为......”或“BundleException：捆绑中未解决的约束......无法解决......缺少要求...... osgi.wiring。包”日志中的那种消息，自动来自 Felix 框架和/或文件安装包？我没有看到类似的东西 - 我应该是吗？在哪里？

我还添加了日志记录（通过 Apache Felix Log 和 osgi-loglistener-slf4j），但仍然没有 - 您是否需要比我做的更多才能在（嵌入式）Felix 中启用此类问题的日志记录？

然后我添加了 Felix Gogo Shell CLI，发现它的 inspect 命令也不是很有帮助（不适用于未解析的捆绑包），并且只有 start 会显示根目录原因 - 但是我怎样才能让这个被记录，而不必有一个控制台并开始：

g! lb  
START LEVEL 1
   ID|State      |Level|Name
    0|Active     |    0|System Bundle (5.6.1)|5.6.1
    1|Active     |    1|Apache Felix File Install (3.5.4)|3.5.4
    2|Active     |    1|Apache Felix Remote Shell (1.1.2)|1.1.2
    3|Active     |    1|Apache Felix Gogo Runtime (0.16.2)|0.16.2
    4|Active     |    1|Apache Felix Gogo Command (0.16.0)|0.16.0
    5|Active     |    1|Apache Felix Gogo Shell (0.12.0)|0.12.0
    6|Installed  |    1|osgi.testplugin (1.0.0.SNAPSHOT)|1.0.0.SNAPSHOT
g! inspect req * 6
Bundle 6 is not resolved.
g! start 6
org.osgi.framework.BundleException: Unable to resolve ch.vorburger.minecraft.osgi.testplugin [8](R 8.0): missing requirement [ch.vorburger.minecraft.osgi.testplugin [8](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.spongepowered.api.command) Unresolved requirements: [[ch.vorburger.minecraft.osgi.testplugin [8](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.spongepowered.api.command)]

我明白由于 OSGi 的异步包初始化，何时记录失败的包启动可能并不明显，因为它可能必须等待依赖包出现？难道它还不能……在某种宽限期之后记录这种错误吗？

【问题讨论】：

标签： java osgi apache-felix gogo-shell

【解决方案1】：

在我找到 pax 考试选项来检查所有捆绑包是否已解决之前，我在测试中遇到了类似的问题。

我所做的是以编程方式遍历捆绑包列表，并在每个未启动的捆绑包上调用 start。 bundle.start() 然后抛出异常，原因类似于上面的控制台命令。

不确定 felix 是否可以设置为默认也记录此内容。

【讨论】：

Right.. 所以这里的问题真的不是 Felix Framework 核心，而是文件安装包“吞下”了 bundle.start() 的异常，它在启动时或当它执行时注意到它监视的目录的变化？这是一个公平的错误报告，也许是一个 LOG error() 或 warn() 的贡献是明智的？或者它可能是故意吞下的 - 当文件安装应该忽略捆绑启动错误而不记录时，是否存在可以想象的场景（可能是因为它会重试，因此“污染”日志是不可取的）？
绝对值得在 felix 开一个问题。也许 fileinstall 可以配置为显示错误，但它也可能是一个错误。

【解决方案2】：

不确定这是最好的解决方案，但它帮助了我

import org.osgi.framework.*;

public class Activator implements BundleActivator, BundleListener {

    public void start(BundleContext context) {
        context.addBundleListener(this);
    }

    public void stop(BundleContext context) {
        context.removeBundleListener(this);
    }

    @Override
    public void bundleChanged(BundleEvent bundleEvent) {
        if (bundleEvent.getType() == BundleEvent.UNRESOLVED) {
            System.out.println("BUNDLE " + bundleEvent.getOrigin().getSymbolicName() + " UNRESOLVED");
        try{
            System.out.println("TRYING TO START " + bundleEvent.getOrigin().getSymbolicName() + " BUNDLE");
            bundleEvent.getOrigin().start();

        } catch (BundleException e) {
            e.printStackTrace();
        }

    }
}

}

并将激活器配置添加到 .bnd 文件

Bundle-ClassPath: .
Bundle-Activator: com.netcracker.webportal.framework.activator.Activator
Import-Package: org.osgi.framework

【讨论】：