Определение имени родителя или суперпользователя с помощью logback - PullRequest
Новая
       47

Определение имени родителя или суперпользователя с помощью logback

0 голосов
/ 07 июня 2018

Я работаю над большим проектом со многими подмодулями.При отладке компонента xyz этот компонент часто обращается к сервисам в других модулях.Чтобы регистрировать каждое отладочное сообщение, мы должны определить множество регистраторов в нашем logback.xml.

Можно ли определить всеобъемлющие супер-регистраторы или родительские регистраторы?

пример: вместо записи этого: 

<logger name="com.a.b.c.xyz" level="debug" />
<logger name="com.a.b.d.core.xyz" level="debug" />
<logger name="com.a.b.e.xyz" level="debug" />
<logger name="com.a.b.e.f.xyz" level="debug" />
<logger name="com.a.b.t.services.xyz" level="debug" />

Можно определить что-то вроде этого: 

<logger name="xyz-super" level="debug">
    <child-logger name="..." />
    <child-logger name="..." />
    ...
</logger>

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

1 Ответ

0 голосов
/ 08 июня 2018

Если я понимаю, о чем вы спрашиваете, у вас есть понятие «компонент», который пересекает пакеты Java, и вы хотите обрабатывать настройку уровня ведения журнала на основе того, в каком компоненте он находится, а не обязательно на какомпакет, в котором он находится. Я вижу несколько подходов, которые можно использовать.

  1. В то время как стандарт имени регистратора основан на имени класса (и, следовательно, пакета Java, в котором находится класс),вам не нужно , чтобы использовать это для имен ваших регистраторов.То есть у вас может быть иерархия логгера, которая отличается от иерархии вашего пакета.В вашем классе com.a.b.c.xyz вы можете получить регистратор с: 

    final Logger logger = LoggerFactory.getLogger("com.a.b.xyz.c");

    В вашем классе com.a.b.d.core.xyz получить регистратор с: 

    final Logger logger = LoggerFactory.getLogger("com.a.b.xyz.d.core");

    И тогда вы можете простоиспользуйте обычные определения уровня ведения журнала, установив уровень ведения журнала для com.a.b.xyz, чтобы получить все средства ведения журнала под этим компонентом.Это немного нетрадиционно, и может запутать разработчиков, плохо знакомых с вашим проектом, но если вы действительно хотите, чтобы иерархия журналирования и иерархия пакетов были разными, это то, что вы можете сделать.

  2. ДругойПодход заключается в том, чтобы оставить иерархию имен журналирования как есть, но использовать механизм SLF4J / Logback Marker , чтобы «пометить» каждое сообщение журнала для каждого компонента.

    final Logger logger = LoggerFactory.getLogger(getClass());
final Marker xyzComponent = MarkerFactory.getMarker("XYZ");
…
logger.info(xyzComponent, "A log message");

    Затем вы можете настроить Фильтры в Logback на основе искомых маркеров.Это требует, чтобы вы были последовательны и удостоверились, что каждое сообщение, о котором вы заботитесь, помечено соответствующим маркером, но это самая близкая вещь к «супер логгеру» или «групповому логгеру», который есть в архитектуре SLF4J.Механизм маркеров действительно мощный и позволяет вам делать с ним практически все, если ваши сообщения имеют правильный маркер и вы настраиваете свою конфигурацию ведения журнала так, чтобы фильтровать только сообщения с правильным фильтром.

  3. Другой подход, который я могу придумать, заключается в том, чтобы в основном продолжать делать то, что вы делаете сейчас, и указывать множество отдельных регистраторов на уровне отладки, но иметь эту «отладочную» запись в журналНастройки конфигурации для каждого компонента в отдельных файлах.Затем, когда вам нужно отладить компонент, вам просто нужно добавить (или раскомментировать?) Соответствующий элемент include в ваших основных настройках ведения журнала.

    В файле xyz-debug.xml:

    <included>
    <logger name="com.a.b.c.xyz" level="debug" />
    <logger name="com.a.b.d.core.xyz" level="debug" />
    <logger name="com.a.b.e.xyz" level="debug" />
    <logger name="com.a.b.e.f.xyz" level="debug" />
    <logger name="com.a.b.t.services.xyz" level="debug" />
</included>

    В файле abc-debug.xml: 

    <included>
    <logger name="com.a.b.c.abc" level="debug" />
    <logger name="com.a.b.d.core.abc" level="debug" />
    <logger name="com.a.b.e.abc" level="debug" />
    <logger name="com.a.b.e.f.abc" level="debug" />
    <logger name="com.a.b.t.services.abc" level="debug" />
</included>

    А затем в вашем основном logback.xml: 

    <!--<include file="xyz-debug.xml"/>-->
<!--<include file="abc-debug.xml"/>-->

    И вы просто раскомментируете соответствующиестрока, когда вам нужно отладить этот компонент.Возможно, немного сложновато и упрощенно, и может быть очень запутанно, если кто-то забудет обновить xyz-debug.xml, когда компонент xyz является частью нового пакета, но я могу себе представить, что это работает достаточно хорошо для некоторых команд.Также не требуется никаких изменений кода, что может быть плюсом.

Logback и SLF4J имеют лот мощности и возможностей, что (как обычно)) и сильные и слабые стороны, так как может потребоваться время, чтобы узнать обо всем, что они могут сделать.Но обычно можно найти способ заставить их работать так, как они хотят, а иногда можно найти способ даже лучше, чем задумал.

...