Использование OSGi LogService в реальном приложении

Question

Как правильно использовать OSGi LogService в реальных приложениях? Сначала я решил использовать декларативные службы для создания компонентов, если класс должен что-то регистрировать. Тем не менее, это означает, что вы должны объявить компонент службы практически для каждого отдельного класса, что кажется излишним и трудным в обслуживании. Это особенно верно, когда вам нужно превратить большинство классов в фабрики компонентов, которые являются просто вспомогательными классами.

Кроме того, это не очень хорошо работает с абстрактными классами и не финальными классами, поскольку разработчик, расширяющий класс, должен убедиться, что он / она объявляет компонент с теми же ссылками, что и базовый класс. Это особенно верно для системы, которую я разрабатываю, которая, по сути, предоставляет библиотеку, содержащую абстрактные классы, которые будут использовать другие разработчики.

Текущее решение предоставляет методы статического журнала, которые используют статический экземпляр ссылки LogService. Однако поставщик LogService обрабатывает все сообщения журнала как поступающие из пакета, который содержит класс статического журнала.

Answer 1

В OSGi (как и в любой среде) вы хотите как можно больше держаться подальше от статических помощников, поэтому решения с использованием метода статического журнала - не лучший способ.Работая в среде OSGi, вы захотите использовать LogService в качестве центрального, связанного с пакетами и обслуживанием канала для всех ваших журналов.Необходимо рассмотреть два случая.

Устаревший и библиотечный код

Если код, который вы используете, требует ведения журнала, но не знает OSGi, вы можете построить (или найти) мосты к LogService.

Код под вашим контролем

Предполагая, что весь код под вашим контролем должен быть ориентирован на обслуживание, он должен использовать LogService напрямую.Для большинства компонентов это легко, но в некоторых случаях требуется дополнительное рассмотрение.

• Для абстрактных классов все зависит от того, для чего вы их используете.

  • Это базовые классы, которые помогают вам с деталями OSGi?Тогда декларативные сервисы могут оказаться не лучшим выбором, вы можете посмотреть на другие механизмы управления зависимостями, которые по-разному обрабатывают наследование.
  • Обеспечивают ли они базовую функциональность, не поддерживающую OSGi?В этом случае проблем не должно быть, поскольку ваш конкретный подкласс будет зарегистрирован как компонент.
• Мы все сталкиваемся с ситуацией, когда код библиотеки , по-видимому, нуждается в регистрации;однако спросите себя, действительно ли это так.Очень общий код редко может знать, что он должен регистрировать.Если он знает достаточно о вашей ситуации, он, вероятно, должен быть расположен в компоненте, делегируя детали в фактический библиотечный код.В исключительных ситуациях, требующих ведения журнала, вам, вероятно, следует использовать исключения.
• Вам действительно нужно регистрироваться из кода, не поддерживающего обслуживание?Вы можете передать LogService вспомогательным методам (так, по крайней мере, мы знаем, от имени кого выполняется этот код).

Особый случай, который следует учитывать, - это длительные операции, которые не являются OSGi.-aware: если вы даете сервисную ссылку, например, на рабочий поток, который может работать очень долго, вы напрашиваетесь на проблемы, а не только на регистрацию.