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

Question

在真实世界的应用程序中使用OSGi LogService的正确方法是什么？起初，我想如果一个类需要记录某些内容，我会使用Declarative Services来创建组件。但是，这意味着你必须为几乎每一个类都声明一个服务组件，这似乎有点过分而且难以维护。当您需要将大多数类放入只是辅助类的组件工厂时，尤其如此。

此外，对于抽象类和非final类，这不能很好地工作，因为扩展类的开发人员必须确保他/她声明一个与基类具有相同引用的组件。在我正在开发的系统中尤其如此，它实际上提供了一个包含其他开发人员将使用的抽象类的库。

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

Answer 1

在OSGi中（如在任何环境中），您希望尽可能远离静态助手，因此，静态日志方法解决方案不是最好的方法。当您在OSGi环境中运行时，您将需要使用LogService作为所有日志记录的中央，捆绑和服务感知管道。有两种情况需要考虑。

旧版和库代码

如果您使用的代码需要记录功能，但不能识别OSGi，则可以构建（或找到）LogService的桥梁。

您控制下的代码

假设您控制的所有代码都应该是服务感知的，它应该直接使用LogService。对于大多数组件而言，这很容易，但有些情况需要额外考虑。

• 对于抽象类，一切都取决于你使用它们的目的。

  • 它们是帮助您了解OSGi详细信息的基类吗？然后，声明性服务可能不是您最好的选择，您可以查看以不同方式处理继承的其他依赖关系管理机制。
  • 他们是否提供非OSGi感知基本功能？这种情况应该没有问题，因为您的具体子类将被注册为组件。
• 我们都遇到库代码似乎需要记录的情况;但是，问问自己是否确实如此。非常通用的代码很少知道它应该记录什么。如果它对您的情况了解得足够多，它可能应该位于一个组件中，将详细信息委托给实际的库代码。对于保证记录的特殊情况，您应该使用例外。
• 您真的需要从非服务感知代码登录吗？您可以将LogService传递给帮助程序方法（因此至少我们知道代码的执行者是谁）。

需要考虑的一个特殊情况是长期运行的操作不能识别OSGi：例如，如果你提供一个服务引用，例如，一个可能运行很长时间的工作线程，你就会遇到麻烦，而不是仅用于记录。