在实际应用程序中使用OSGi LogService

在实际应用程序中使用OSGi LogService的正确方法是什么？起初，我想如果类需要记录某些内容，我会使用声明性服务来创建组件。然而，这意味着您必须为几乎每一个类声明一个服务组件，这看起来有些过分，维护起来也很痛苦。当您需要将大多数类转换为只是辅助类的组件工厂时，尤其如此

此外，这对于抽象类和非最终类也不太有效，因为扩展类的开发人员必须确保他/她声明的组件引用与基类相同。在我正在开发的系统中尤其如此，该系统本质上提供了一个包含其他开发人员将使用的抽象类的库

当前的解决方案是提供使用LogService引用的静态实例的静态日志方法。但是，LogService提供者将所有日志消息视为来自包含静态日志类的捆绑包。

在OSGi中（就像在任何环境中一样），您希望尽可能远离静态助手，因此，静态日志方法解决方案并不是最好的方法。当您在OSGi环境中运行时，您将希望使用

LogService

作为所有日志记录的中心、捆绑和服务感知管道。有两种情况需要考虑。

遗留和库代码 如果您使用的代码需要日志功能，但不支持OSGi，则可以构建（或查找）到

LogService

的桥接

代码在您的控制之下 假设您控制的所有代码都应该是服务感知的，那么它应该直接使用

LogService

。对于大多数组件，这很容易，但有些情况需要额外考虑

• 对于抽象类，这完全取决于您使用它们的目的
  • 它们是帮助您了解OSGi细节的基类吗？那么声明性服务可能不是最好的选择，您可以研究其他以不同方式处理继承的依赖关系管理机制
  • 它们是否提供不支持OSGi的基本功能？这种情况应该没有问题，因为您的具体子类将注册为组件
• 我们都会遇到库代码似乎需要记录的情况；然而，问问你自己，它是否真的如此。非常通用的代码很少知道应该记录什么。如果它足够了解您的情况，它可能应该位于组件中，将详细信息委托给实际的库代码。对于需要记录日志的异常情况，您可能应该使用异常
• 您真的需要从非服务感知代码登录吗？您可以将

  LogService

  传递给helper方法（这样至少我们知道这段代码是代表谁执行的）

---

一个特殊的案例是不运行OSGi的长时间运行的操作：如果你提供了一个服务引用，例如，一个可能运行很长时间的工作者线程，那么你就是在自找麻烦，不仅仅是日志记录。

问题在于我们正在创建抽象类供其他人实现，而当前的体系结构不要求实现抽象类的人使用声明性服务。即使将具体类声明为组件，这也很容易出错，因为LogService引用是可选的，因此某些人认为会发生的日志记录（因为他们进行了调用）在运行时不会发生，当您有多个嵌套对象的级别，而您必须在多个对象之间向下传递引用时，这种方法的伸缩性不是很好。此外，当您拥有一个动态服务时，您必须注意保持所有内容的同步，以防该服务消失。在日志服务传递时：确切地说，它不可扩展，因此更有理由不以这种方式使用它。我觉得，如果您需要从“真实”库代码登录，那么您在对应用程序进行分区时犯了一些错误。