OSGi:如何确保类路径一致性？

Question

根据OSGi文档,OSGi旨在帮助防止ClassPath问题.

例如,从"OSGi in action":

启动应用程序时ClassNotFoundExceptions,因为类路径不正确.在允许代码执行之前,OSGi可以通过确保满足代码依赖性来提供帮助.

但是,因为我们已经将我们的java应用程序切换到OSGi,所以我看到了比以往更多的ClassNotFoundExceptions,尤其是NoClassDefFoundErrors.OSGI类加载器不再能够找到以前加载正常的类,更糟糕的是:在运行时遇到错误,这意味着除非通过手动测试应用程序的每个角落,否则无法轻松检查它.

例如,我们的应用程序在OSGi下运行愉快,但我们收到了beta测试人员的报告,他们无法再将文档导出为PDF.实际上,当我查看它时,我发现此功能导致异常被记录:

java.lang.NoClassDefFoundError: org/w3c/dom/Node

那么,OSGi实际上是否创造了比它解决的更多的类路径问题？

更重要的是:在我在错误报告中阅读它们之前,如何测试我的类路径是否一致,所有必需的Import-Package语句等？

Answer 1

如果清单正确,OSGi应用程序将不会抛出ClassNotFoundExceptions和NoClassDefFoundErrors .也就是说,您需要告诉OSGi您的捆绑包使用哪些包; 如果你没有正确或诚实地做到这一点,那么OSGi无法帮助你.换句话说:GIGO(Garbage In,Garbage Out).

例如,您使用该包org.w3c.dom但未在Import-Package语句中列出它.因此,OSGi不知道您需要访问该包,因此当您实际尝试从该包加载类时,它们不可用.

因此,您需要确保您的Import-Package声明对于捆绑包实际使用的包是准确的.好消息是"bnd"工具可以通过生成包清单来为您完成此操作,使用字节码分析来查找所有静态引用的包.

更新: 您的最后一个问题是在运行时发现问题之前询问如何测试捆绑包是否一致.Bnd有一个"验证"功能,正是这样做的.实际上,如果您首先使用Bnd生成清单,那么您将不需要验证功能.但是,我对您的构建过程一无所知,因此您可能会发现很难在短期内转向基于Bnd的构建......在这种情况下,将验证任务添加为后期相对简单构建后的处理步骤.但是我仍然建议在构建过程中尽早使用Bnd.