打印 OSGI 包类路径？
在普通的 java 应用程序中，可以使用以下命令打印类路径的内容：
String ss = System.getProperty("java.class.path");
System.out.println(ss);
但是如何打印使用 eclipse PDE 向导创建的 OSGI 包的类路径呢？在激活器中，可以获取当前包，例如：
public void start(BundleContext context) throws Exception { super.start(上下文); 插件=这个；
Bundle b = context.getBundle();
// java doc: This bundle's class loader is not used to search for entries.
b.findEntries(path, filePattern, recurse)
但 javadoc 说 findEntries 不使用类加载器。有没有简单的方法可以查看/打印当前包的类路径上的内容？
In a normal java application its possible to print the content of the classpath with:
String ss = System.getProperty("java.class.path");
System.out.println(ss);
But how do I print the classpath of an OSGI bundle created using the eclipse PDE wizard? In the activator its possible to get the current bundle like:
public void start(BundleContext context) throws Exception {
super.start(context);
plugin = this;
Bundle b = context.getBundle();
// java doc: This bundle's class loader is not used to search for entries.
b.findEntries(path, filePattern, recurse)
But the javadoc says that the findEntries does NOT use the class loader. Is there any simple way to see/prints what is on the current bundle's classpath?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正如其他人指出的那样，实际上不存在“捆绑类路径”这样的东西——这就是 OSGi 的全部意义。 :)
您可以做的是：
查看您的捆绑包的标头，了解它导入了哪些包，以及它们是否是必需的或强制的
使用 PackageAdmin 查找导出具有给定名称的包的捆绑包
但是 AFAIK PackageAdmin 已弃用，并且将有一个新的/扩展的机制可以工作4.3 中的捆绑接线。
看来您这样做的真正动机是类路径扫描以查找和查找加载资源。事实上，这并不容易实现，这是强制模块边界的副作用：你不能在有围栏的同时允许任何人在草坪上行走。
有一个代表客户扫描捆绑包的标准服务计划，但该计划似乎已被撤回（不确定原因 - 可能是新的 4.3 内容的结果）。
As others have indicated there is really no such thing as a "bundle classpath" - that's the whole point of OSGi. :)
What you can do is:
look at your bundle's headers to see which packages it imports, and whether they are required or mandatory
use PackageAdmin to find bundles that export packages with a given name
However AFAIK PackageAdmin is deprecated and there will be a new/extended mechanism to work with bundle wiring in 4.3.
It seems like your real motivation for this is classpath scanning to find & load resources. The fact that this is not easily possible is a side effect of enforcing module boundaries: you can't have a fence and at the same time allow anyone to walk on the lawn.
There was a plan for a standard service that scans bundles on behalf of a client, but that seems to have been withdrawn (not sure why - maybe as consequence of the new 4.3 stuff).