Как правильно вести журнал в OSGi при разделении сервисных компонентов?

Я работаю с OSGi и декларативными сервисами (DS) и в настоящее время думаю о том, как правильно вести журнал. Поскольку я все равно работаю с DS, кажется естественным использовать LogService, указанный в сборнике сервисов OSGi, в качестве обязательной ссылки на сервис. Я много читал в сети на угол ekkes и блог nogunners, но что-то мне до сих пор непонятно:

Как правильно различать разные сервисные компоненты (или разные экземпляры сервисных компонентов при использовании факторизованных компонентов)?

Если я посмотрю на реализацию LogListener nogunners с использованием Logback, он использует форму Bundle-Id из контекста пакета, чтобы различать их. Хорошо, пока. Но как бы я различал сервисные компоненты? Объект LogService естественно содержит ссылку на BundleContext, но (смотря в интерфейс LogService) ServiceReference должен быть предоставлен самим пользователем (тот, кто действительно что-то регистрирует)? Мне это кажется хрупким. Почему фреймворк не может предоставить это, поскольку он предоставляет BundleContext?

И пока я на этом, почему спецификация OSGi использует многословный logger.log(LogService.LOG_INFO,...) вместо квазистандартного logger.info(...), logger.warn(..) и т. д.? Есть ли какая-то конкретная причина для этого?


person benjamin    schedule 08.05.2012    source источник


Ответы (1)


Не существует стандартного способа регистрации идентификатора компонента, вам придется встроить его в сообщение.

Службе логов OSGi уже 14 лет... Было решено не апгрейдить ее, потому что вокруг уже было и так (слишком) много систем логирования.

Посмотрите на http://team.ops4j.org/wiki/display/paxlogging/Pax+Logging, они интегрируют популярные регистраторы с OSGi (в обоих направлениях).

person Peter Kriens    schedule 10.05.2012
comment
Спасибо за быстрый ответ, я повнимательнее посмотрю на Pax Logging. Но поскольку мне действительно нужна точная дифференциация компонентов, а не только встроенная в сообщение, я, вероятно, выберу собственную реализацию... - person benjamin; 11.05.2012
comment
Некоторое пояснение: использование ServiceFactory для службы ведения журналов позволяет предоставлять разные экземпляры службы для разных пакетов и, таким образом, отслеживать их BundleContext. Я предполагал, что это будет возможно и для ComponentContext. Плохая новость: это не так, потому что фреймворку разрешено кэшировать экземпляры службы и повторно использовать их, когда один и тот же пакет запрашивает службу. Как следствие, вы не можете выделить разные услуги из одного пакета. Имхо плохой дизайн. См. osgi.org/javadoc/r4v43/core/org. /осги/фреймворк/ - person benjamin; 11.05.2012
comment
Я решительно поддерживаю рекомендацию Pax-Logging. Я использую его с SLF4J. Если вы используете Apache-Karaf, Pax-Logging поставляется уже в комплекте. - person Chris Dolan; 12.05.2012