在运行时获取已安装的OSGI包列表

时间:2012-06-11 11:44:31

标签: osgi equinox

我的应用程序从属性文件中获取类名。由这些类名表示的类可以驻留在某些未知的OSGI包中,因此为了实例化它们,我首先必须找到这些类所属的包。我正在考虑从BundleContext#getBundles获取所有已安装的bundle,这意味着我必须在AbstractUIPlugin #start中获得对BundleContext的引用。但我不确定持有对BundleContext的引用是否正确,因为它只应该在start方法中使用。因此,我需要OSGI专家提供有关获取捆绑包列表的替代方案的建议。

非常感谢任何帮助。

此致

Setya

3 个答案:

答案 0 :(得分:5)

这不是OSGi的真正意图。如果捆绑包有某些内容要添加到“全局”上下文中,则应注册服务。因此,每个具有共享内容的bundle都可以在自己的start方法中完成。

其他一些组件(DS,ServiceTracker,Blueprint,类似的东西)可以监听这些事件,并采取相应的行动。

这非常重要,如果您开始手动搜索所有捆绑包,则会完全失去OSGi的优势。

答案 1 :(得分:1)

像你之前写的那样,你应该尝试使用服务来实现你想要的。我猜你有一个接口,它有一个或多个应该可以在运行时安装的实现。因此,如果您控制实现该接口的bundle,那么只需让他们通过使用Activator或蓝图上下文将其实现作为服务安装。您可以使用服务属性来描述您的实现。

然后,需要实施的捆绑包可以使用服务跟踪器或蓝图中的服务引用来查找服务。

如果那是不可能的,那么你可以使用bundle上下文来获取正在运行的bundle并实例化类,但这不是OSGi应该如何工作的。您将遇到类加载问题,因为尝试实例化类的bundle将无法直接访问它们。

答案 2 :(得分:1)

您的捆绑包在启动时通过捆绑激活器获得控制权,或者更好地通过DS获得控制权。那时它可以向服务注册表注册服务,以便其他人可以找到/使用它们。

您计划前往的路线(名称类的属性)是邪恶的,因为您无疑会在类加载地狱中运行。模块化是关于隐藏您的实现细节,您的实现类的名称是这样的细节。

在属性文件中公开实现类是非常糟糕的做法,它失去了模块化的优势。如果另一个类引用您的实现类或属性文件并不重要,问题在于impl。上课暴露。

不幸的是,这种模式在我们的行业中变得如此普遍,许多开发人员认为这是正常的: - (

OSGi允许您以允许实现类仅在模块内部知道的方式共享由接口键入的实例。