我的应用程序从属性文件中获取类名。由这些类名表示的类可能驻留在预先未知的某些 OSGI 包中，因此为了实例化它们，我首先必须找到这些类属于哪个包。我正在考虑从 BundleContext#getBundles 获取所有已安装的包，这意味着我必须在 AbstractUIPlugin#start 中获取对 BundleContext 的引用。但我不确定持有对 BundleContext 的引用是否正确，因为它应该只在 start 方法中使用。所以我在这里需要 OSGI 专家的建议，了解获取捆绑包列表的替代方法。
任何帮助将不胜感激。
问候，
塞提亚
【问题讨论】：
这并不是 OSGi 的真正意图。如果一个包有一些东西要添加到“全局”上下文中，你应该注册一个服务。所以每个有东西要共享的包都可以在自己的 start 方法中做到这一点。
然后其他一些组件（DS、ServiceTracker、Blueprint 等）可以监听这些事件并采取相应的行动。
这非常重要，如果您开始手动搜索所有捆绑包，您将完全失去 OSGi 的优势。
【讨论】：
就像之前写的一样，你应该尝试使用服务来实现你想要的。我猜你有一个接口应该可以在运行时安装一个或多个实现。因此，如果您控制实现接口的包，那么只需让它们通过使用 Activator 或蓝图上下文将其实现安装为服务。您可以使用服务属性来描述您的实现。
然后，需要实现的捆绑包可以使用服务跟踪器或蓝图中的服务引用来查找服务。
如果这不可行，那么您可以使用包上下文来获取正在运行的包并实例化类，但这不是 OSGi 应该工作的方式。您将遇到类加载问题，因为尝试实例化类的包将无法直接访问它们。
【讨论】：
您的捆绑包在启动时通过捆绑激活器获得控制权，或者更好的是通过 DS。那时它可以向服务注册表注册服务，以便其他人可以找到/使用它们。
您计划走的路线（命名类的属性）是邪恶的，因为您无疑将在类加载地狱中运行。模块化就是隐藏你的实现细节，你的实现类的名字就是这样的细节。
在属性文件中公开实现类是非常糟糕的做法，它失去了模块化的优势。另一个类是否引用您的实现类或属性文件都没有关系，问题在于 impl.类暴露。
不幸的是，这种模式在我们的行业中变得如此普遍，以至于许多开发人员认为这是正常的:-(
OSGi 允许您共享接口类型化的实例，这种方式只允许在模块内部知道实现类。
【讨论】：