1

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

任何帮助将不胜感激。

问候，

塞提亚

4

3 回答 3

5

这并不是 OSGi 的真正意图。如果一个包有一些东西要添加到“全局”上下文中，你应该注册一个服务。所以每个有东西要共享的包都可以在自己的 start 方法中做到这一点。

然后其他一些组件（DS、ServiceTracker、Blueprint 等）可以监听这些事件，并采取相应的行动。

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

于 2012-06-11T12:29:41.903 回答
1

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

您计划走的路线（命名类的属性）是邪恶的，因为您无疑将在类加载地狱中运行。模块化就是隐藏你的实现细节，你的实现类的名字就是这样的细节。

在属性文件中公开实现类是非常糟糕的做法，它失去了模块化的优势。另一个类是否引用您的实现类或属性文件都没有关系，问题在于 impl. 类暴露。

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

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

于 2012-06-12T07:02:00.373 回答
1

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

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

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

于 2012-06-11T18:31:27.610 回答