Подтвердить что ты не робот

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

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

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

См. также

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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


EDIT: Похоже, я ошибся в обосновании ведения журнала Commons. Связи, данные @Pascal Thivent, особенно первая, объясняют это намного лучше.

Ответ 4

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

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

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

Если вы можете, перейдите на slf4j.