Где определить статический регистратор всего приложения?

Question

В моем веб-приложении на Java есть несколько пакетов.В некоторых из них я использую эту конструкцию:

public class Foo {
  private static Logger logger = LoggerFactory.getLogger("com.XXX");
  public void bar() {
    Foo.logger.debug("Method bar() was just called");
  }
}

Конечно, это всего лишь пример.Все работает нормально, но мне не нравится идея инициализации логгера во многих классах.Это очевидное дублирование кода.Я хотел бы переместить его в какой-нибудь вспомогательный класс и разрешить доступ к нему всем остальным классам.Это правильная идея?Или, может быть, есть какая-то другая "лучшая практика" или шаблон?

Answer 1

Сказать, что это дублирование кода, все равно что сказать, что наличие import java.util.* в 75% ваших классов - это дублирование кода.Или то, что вы пишете public class ... слишком часто.Это не дублирует логика .Это дублирующий шаблонный код.

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

С другой стороны, вы теряете возможность точной настройки ведения журнала, если отказываетесь от иерархической структуры.

Answer 2

Я не думаю, что вы выиграете что-либо, если будете использовать централизованную глобальную статическую запись в логгере, отличную от обычных вызовов / inits Log4J.

Если вы напишите

private static Logger logger = LoggerFactory.getLogger("com.XXX");
logger.info("Hello World");

или что-то ещевот так

GlobalLogger.info(this, "LogMessage");  //Singleton...

... не сделает ваш код более "читабельным".

Answer 3

Вы можете написать свой собственный служебный класс, который оборачивает глобальный регистратор и реализует статические делегаты для методов регистратора.Затем просто выполните статический импорт этого класса:

public class MyLogger {
  private static Logger logger = LoggerFactory.getLogger("application");

  public static void debug(String s) {logger.debug(s));}

  public static void debug(Class<?> caller, String s) {
     LoggerFactory.getLogger(caller.getName()).debug(s);
  }

  // ...
}

Использование:

import static MyLogger.*;

public class Foo {
  public void bar() {
    // makes use of static import!
    debug("Method bar() was just called"); 
    debug(this.getClass(), "Method bar() was just called"); 
  }
}

Добавлена ​​перегруженная версия примера делегата debug, который принимает объект класса и использует соответствующийLogger.

Answer 4

Инкапсуляция сторонней зависимости (т. Е. Log4j) с классом служебного журнала имеет смысл.

Например, если команда решит переключиться с Log4j на NextBigThingLogger, она просто обновит свой класс MyLogger, и никтодругих классов приложений.

Более чистый и простой в обслуживании.

API-интерфейсы Apache и даже сам язык Java заполнены "запахами дизайна", но это не значит, что мы не должныответить на них.

Answer 5

Это не рекомендуется, так как вы потеряете возможности иерархического ведения журнала Log4j (если это то, что вы используете), где очень полезно добавлять разные дополнения на разных уровнях дерева пакетов. Я бы не стал этого делать, поскольку вы потеряли бы информацию о том, какой класс создал сообщение журнала.

Answer 6

Вы можете создать шаблон адаптера для регистратора. В моем случае я расширил регистратор, включив в него все функции регистратора. Затем он превращается в синглтон.

public class LoggerAdapter extends Logger {
    private LoggerAdapter instance;
    private Logger logger;

    private LoggerAdapter() {

    }

    public static LoggerAdapter getInstance(Clazz<?>  clazz) {
        if (instance == null) {
            instance = new LoggerAdapter();
        }
        instance.logger = logger = LoggerFactory.getLogger(clazz.getName());

        return instance;
    }

    @Override
    public void trace(Object object) {
        logger.trace(object);
    }

    //Other overridden methods here...
};

В основном, динамически изменяющийся регистратор ....

Answer 7

Я думаю, что вы придерживаетесь шаблона проектирования Singleton. Не будучи программистом Java, я выкопал это из Google:

http://www.javacoffeebreak.com/articles/designpatterns/index.html