Используя тот же log4j logger в автономном Java-приложении

Question

У меня есть некоторый код, который представляет собой отдельное Java-приложение, состоящее из 30+ классов.

Большинство из них наследуются от некоторых других базовых классов.

Каждый класс имеет этот метод для получения и использования log4j logger

public static Logger getLogger() {
    if (logger != null) return logger;
    try {
        PropertyUtil propUtil = PropertyUtil.getInstance("app-log.properties");
        if (propUtil != null && propUtil.getProperties() != null)
            PropertyConfigurator.configure(propUtil.getProperties ());
        logger = Logger.getLogger(ExtractData.class);
        return logger;
    } catch (Exception exception) {
        exception.printStackTrace();
    }
}

A) Мой вопрос заключается в том, должен ли он быть реорганизован в какой-либо общий логгер, который инициализируется один раз и используется всеми классами? Это лучшая практика?

B) Если да, как это можно сделать? Как я могу передать регистратор вокруг?

C) На самом деле это используется в коде не как Logger.debug(), а getLogger().debug(). Как это влияет на производительность?

Answer 1

A) в Log4J у вас есть иерархии регистраторов, а не один регистратор.Обычно это сводится к одному регистратору на класс, где регистраторы идентифицируются по имени класса.Регистратор инициализируется следующим образом:

private static final Logger logger = Logger.getLogger(MyClass.class);

Это хорошая практика, так как он позволяет вам точно настроить поведение журналирования для модулей (пакетов) или даже отдельных классов в вашем приложении.Таким образом, вы можете отключить ведение журнала для некоторых пакетов, войти на уровне INFO в других и войти на уровне DEBUG для некоторых критических классов, например, когда вы хотите поймать ошибку.

B) Однако, если вы хотите один регистраторвезде, просто используйте корневой логгер в каждом классе:

private static final Logger logger = Logger.getLogger();

C) для вызовов не слишком сложных методов, разница в производительности, вероятно, незначительна, так как JIT-компилятор в любом случае агрессивно встроит вызовы.Для сложных методов это скорее открытый вопрос.

Обратите внимание, что метод, который вы показываете, выполняет ненужную работу, загружая конфигурацию регистратора - это делается автоматически Log4J, если вы называете свой файл конфигурации log4j.properties и помещаете его впуть к классамТем не менее, даже если вам нужно использовать нестандартное имя файла конфигурации, вы все равно можете загрузить конфигурацию Log4J в одном месте при запуске и опустить отложенную загрузку регистратора.Тогда то, что осталось, это

private static final Logger logger = Logger.getLogger(ExtractData.class);

private static Logger getLogger() {
    return logger;
}

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

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

Answer 2

A) Зависит, но я думаю, что гранулярность регистраторов для каждого класса является частью полезности использования log4j.Вы можете перенаправить информацию журнала из одного класса, если хотите, или отправить их все в один и тот же файл.

B) Вы не будете передавать регистратор, вы просто используете метод Logger.getLogger(), чтобы использоватьroot logger.

C) Вероятно, не большой с точки зрения производительности.Если он еще не статичен, можно указать ваш getLogger() метод как final и указать, что он должен быть встроенным.Ответ Питера здесь лучше, и, как он отмечает, если метод достаточно прост, он, вероятно, все равно будет встроен.

Answer 3

Каждый класс может получить свой собственный регистратор как

final static private Logger log = Logger.getLogger("com.company.package.MyClass");

Это позволяет настраивать параметры log4j по классам, которые более гибки, чем стандартный регистратор.