Using OSGi LogService in the Real World

Question

What is the correct way to use OSGi LogService in the real world? At first, I decided that I would use Declarative Services to create components if the class needs to write something. However, this means that you must declare a service component for almost every single class that seems redundant and painful to maintain. This is especially true when you need to make most classes in component factories, which are only helper classes.

In addition, this does not work very well for abstract classes and non-final classes, since the developer extending the class must make sure that he / she declares the component with the same references as the base class. This is especially true on the system I'm developing, which essentially provides a library containing abstract classes that other developers will use.

The current solution provides static logging methods that use a static instance of a LogService link. However, the LogService provider treats all log messages as coming from a package that contains a static log class.

Answer 1

In OSGi (as in any environment) you try to stay away from static assistants as much as possible, therefore solving a static log method is not the best way to go here. When you start the OSGi environment, you will want to use LogService as the central, connecting, and serving channel for all your protocols. Two cases are considered.

Legacy and library code

If the code you use requires a logging function but does not know OSGi, you can build (or find) bridges in LogService .

Code under your control

Assuming all the code under your control should be serving, it should use LogService directly. For most components, this is easy, but in some cases additional consideration is required.

• For abstract classes, it all depends on what you use them for.

  • Are they base classes that help you with OSGi details? Then declarative services may not be the best choice, you can explore other dependency management mechanisms that handle inheritance differently.
  • Do they provide basic functionality that does not support OSGi? This case should not be a problem, since your particular subclass will be registered as a component.
• We all face a situation where library code seems to need to be registered; however, ask yourself if this is really happening. Very general code rarely knows what it should register. If he knows enough about your situation, he probably should be located in the component, delegating the details to the actual library code. In exceptional situations that require registration, you should probably use exceptions.
• Do you really need to register from code without maintenance? You can pass helper methods to LogService (so at least we know who this code is responding from).

A private consideration is lengthy operations that are not related to OSGi: if you give a link to a service, for example, a workflow that can work for a very long time, you ask for problems, and not just for logging.