В чем проблема с алгоритмом обнаружения во время выполнения Apache Commons Logging - PullRequest
Новая
       3

В чем проблема с алгоритмом обнаружения во время выполнения Apache Commons Logging

42 голосов
/ 11 июля 2010

Дейв Сайер (SpringSource) пишет в своем блоге:

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

Почему? В чем проблема с его алгоритмом обнаружения во время выполнения? Производительность

Ответы [ 4 ]

73 голосов
/ 11 июля 2010

Почему?В чем проблема с его алгоритмом обнаружения во время выполнения?Производительность?

Нет, это не производительность, это боль загрузчика классов .Процесс обнаружения JCL использует хаки загрузчика классов для поиска инфраструктуры журналирования во время выполнения, но этот механизм приводит к многочисленным проблемам, включая непредвиденное поведение, трудно отлаживаемые проблемы загрузки классов, что приводит к увеличению сложности.Это хорошо отражено Ceki (автором Log4J, SLF4J и Logback) в Подумайте еще раз, прежде чем использовать API регистрации общего доступа (который также упоминает проблемы утечек памяти, наблюдаемые в JCL).

И именно поэтому был создан SLF4J, который использует статические привязки.

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

Подводя итог:

  • Да, JCL, как известно, сломан, лучше держаться подальше от него.
  • Если вы хотите использовать фасад для лесозаготовки (не все проекты нуждаются в этом), используйтеSLF4J.
  • SLF4J предоставляет мост JCL-to-SLF4J для каркасов, все еще использующих JCL, таких как Spring: (
  • Я считаю Logback, преемник Log4J, превосходной реализацией ведения журналов.
  • Logback изначально реализует API SLF4J. Это означает, что если вы используете Logback, вы на самом деле используете SLF4J API.

См. Также

11 голосов
/ 11 июля 2010

Commons logging - это легкий каротажный фасад, который размещается поверх API тяжелого каротажа, будь то log4j , java.util.logging или другой поддерживаемый API логирования.

алгоритм обнаружения - это то, что использует протоколирование общего доступа, чтобы определить, какой API ведения журнала вы используете во время выполнения, чтобы он мог перенаправлять вызовы журнала через свой API в базовый API ведения журнала.Преимущество этого заключается в том, что если вы хотите создать библиотеку, которая ведет журналирование, вы не хотите привязывать пользователей вашей библиотеки к какой-либо конкретной системе ведения журналов с большим весом.Вызывающие ваш код могут настроить ведение журналов с помощью log4j, java.util.logging и т. Д., И протоколирование общего достояния будет перенаправлять на этот API во время выполнения.

Общие проблемы для регистрации общего достояния:

  • Evenхотя вы не используете ее, библиотека, от которой вы зависите, может, так или иначе, включать ее в ваш путь к классам.
  • Запускает алгоритм обнаружения для каждого загрузчика классов, в который вы хотите войти, что может выдайте нежелательные результаты , поэтому убедитесь, что вы поместили commons-logging.jar в правильный загрузчик классов.
  • Большая сложность, чем базовая структура ведения журнала.
  • Меньше возможностей, чем базовая структура ведения журнала.

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

2 голосов
/ 11 июля 2010

Я не могу говорить о «непопулярном» аспекте, я могу говорить только за себя:

Commons Logging - это фасад поверх того, чем может быть ваша «реальная» структура ведения журнала: Log4j, Logback или что-то еще.

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

Мои старые Java-приложения напрямую используют Log4j. Работает нормально, не вижу необходимости их менять. Мои новые Java-приложения, вероятно, будут использовать Logback. Я думаю, что возможность динамического выбора каркаса логирования - это то, что никогда не понадобится ни одному из моих приложений. Конечно, пробег других людей может отличаться.

РЕДАКТИРОВАТЬ: Похоже, я был неправ по поводу обоснования Commons Logging. Ссылки, предоставленные @Pascal Thivent, особенно первая, объясняют это гораздо лучше.

1 голос
/ 11 июля 2010

Commons Logging содержит логику для определения во время выполнения, использовать ли log4j или java.util.logging. *.

Этот код раньше был серьезно поврежден, по сути, работал только с JUL.

Основываясь на опыте с этим, был написан slf4j, который использует статическое связывание (или использовал его, я не уверен с версией 1.6), чтобы выбрать подходящую среду для использования log4j, JUL или log4j logback (и более), и включает в себя мост, позволяющий существующему коду регистрации Commons прозрачно использовать slf4j.

Если можете, тогда переходите к slf4j.

...