Логирование с Apache Commons Logging

В этой статье мы будем разбирать даже не фреймворк логирования, а API логирования, которое перенаправляет сообщения лога в другие фреймворки. Как и JUL, и log4j 1.2, и System.err его не стоит использовать в реальных проектах, так как у Apache Commons Logging (ранее Jakarta Commons Logging) слишком много проблем, о которых будет рассказано в конце статьи.

Зачем был нужен Apache Commons Logging? Почему нельзя просто использовать log4j 1,2, JUL, Avalon LogKit или любой другой? На самом деле проблема была очень масштабна. На момент создания Apache Commons Logging существовало огромнейшее количество библиотек логирования для Java, но при этом не было единого стандарта, они все были несовместимы друг с другом. Но ведь в лог писать нужно не только конечным приложениям, но и библиотекам. В какой логер писать библиотеке, если нет единого? И как быть с тем, что каждая библиотека использует свою систему логирования, которая может отличаться от используемой в вашем проекте? Apache Commons Logging должен был решить эту проблему.

Сам по себе Apache Commons Logging не предоставляет никакой реализации логирования. Он лишь определяет интерфейсы, то есть API. Внутри себя он определяет, какую реализацию библиотеки логирования использовать и направляет сообщения в неё.

Apache Commons Logging

Определение библиотеки логирования, которую будет использовать Apache Commons Logging происходит следующим образом:

  1. Смотрится org.apache.commons.logging.Log в файле конфигурации “commons-logging.properties”.
  2. Смотрится org.apache.commons.logging.Log в системных параметрах JVM.
  3. Если библиотека Log4j есть в classpath, то используется она.
  4. Если версия Java > 1.4, то используется java.util.logging.
  5. Если ничего из вышестоящего не помогло, то используется SimpleLogger, который просто пишет все сообщения в System.err.

Сам по себе Apache Commons Logging не содержит какой-бы то ни было конфигурации или реализации логирования, он просто перенаправляет логи в соответствующие библиотеки, а значит, нам нужно настраивать нужную библиотеку вручную в соответствии с её документацией.

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

Как видите, мы просто добавили зависимость commons-logging в качестве API и log4j как реализацию. Так как у нас в classpath теперь есть log4j, то он и должен использоваться Apache Commons Logging. Нам нужно создать файл “log4j.properties”. Мы просто скопируем его из статьи про log4j 1.2:

Единственное, что я поправил, так это то, имя файла лога поменял с “log4j12example.log” на “commonsloggingexample.log”. Теперь мы можем написать тестовое приложение, но использовать будем уже не класс Logger из log4j, а класс Log из Apache Commons Logging:

Эта программа будет писать в консоль и в файл “commonsloggingexample.log” следующие строки:

Вроде выглядит неплохо. Так почему же нельзя использовать Apache Commons Logging в современных приложениях? Основная проблема заключается в том, что реализация логирования в нём определяется на этапе выполнения кода, что приводит к непредсказуемым и трудноразрешаемым последствиям. Например, если вы используете JUL, а какая-нибудь внешняя библиотека подключит log4j, то вместо вашего JUL задействуется log4j, а найти источник проблемы будет очень сложно. Также “commons-logging.properties” может протащить с собой одна из внешних библиотек, что тоже добавит много проблем. Из-за всех этих проблем, а в первую очередь из-за неоднозначности выбора библиотеки логирования во время исполнения, в современном мире при разработке на Java принято использовать Slf4j с Logback.

В последующих статьях я постараюсь описать более современные библиотеки и правильный подход к логированию в Java. Подписывайтесь, делитесь ссылками, вносите пожертвования. Да пребудет с вами Сила!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *