Какова проблема с алгоритмом исследования во время выполнения Apache Вход палаты общин
Dave Syer (SpringSource) пишет в своем блоге:
К сожалению, худшей вещью о входе свободного городского населения, и что сделало это непопулярным у новых инструментов, является также алгоритм исследования во время выполнения.
Почему? Какова проблема с ее алгоритмом исследования во время выполнения? Производительность?
4 ответа
Почему? В чем проблема с его алгоритмом обнаружения во время выполнения? Производительность?
Нет, это не производительность, это боль загрузчика классов. Процесс обнаружения JCL полагается на хаки загрузчика классов для поиска каркаса протоколирования во время выполнения, но этот механизм приводит к многочисленным проблемам, включая неожиданное поведение, трудно отлаживаемые проблемы загрузки классов, что приводит к увеличению сложности. Это хорошо описано Ceki (автором Log4J, SLF4J и Logback) в Подумайте еще раз, прежде чем принять API commons-logging (где также упоминаются проблемы утечки памяти, наблюдаемые в JCL).
И именно поэтому был создан SLF4J, который использует статические привязки.
Ceki является автором SLF4J, вы можете подумать, что его статьи предвзяты, но, поверьте мне, это не так, и он предоставляет множество ссылок (доказательств), чтобы доказать свою точку зрения.
Подведем итоги:
- Да, JCL, как известно, сломан, лучше держаться от него подальше.
- Если вы хотите использовать фасад логирования (не всем проектам это нужно), используйте SLF4J.
- SLF4J предоставляет мост от JCL к SLF4J для фреймворков, все еще использующих JCL, таких как Spring :(
- Я считаю Logback, преемника Log4J, лучшей реализацией логирования.
- Logback изначально реализует API SLF4J. Это означает, что если вы используете Logback, вы фактически используете SLF4J API.
См. также
Я не могу говорить о «считающемся непопулярным» аспекте, я могу говорить только за себя:
Commons Logging — это фасад поверх того, чем может быть ваша «настоящая» структура ведения журналов: Log4j, Logback или что-то еще.
Идея фасада ведения журнала заключается в том, что ваше приложение получает гибкость для принятия решения во время выполнения, с какой реализацией ведения журналов оно хочет работать. Фасады достаточно умны, чтобы найти реализации журналов во время выполнения.
Мои старые приложения Java используют Log4j напрямую. Работает нормально, не вижу необходимости их менять. Мои новые приложения Java, вероятно, будут использовать Logback.Я думаю, что возможность динамического выбора платформы ведения журнала — это то, что никогда не понадобится ни одному из моих приложений. Конечно, пробег других людей может отличаться.
EDIT: Похоже, я ошибся в обосновании ведения журнала на Викискладе. Ссылки, приведенные @Pascal Thivent, особенно первый, объясняют это гораздо лучше.
Ведение журнала Commons - это легкий фасад, который помещается поверх тяжелого API ведения журнала, log4j , java.util.logging или другой поддерживаемый API ведения журналов.
Алгоритм обнаружения - это то, что обычное ведение журнала использует для определения того, какой API ведения журнала вы используете во время выполнения, чтобы он мог направлять вызовы журнала через свой API в базовый API ведения журнала. Преимущество этого состоит в том, что если вы хотите создать библиотеку, которая ведет журнал, вы не хотите привязывать пользователей вашей библиотеки к какой-либо конкретной тяжелой системе ведения журнала. Вызывающие ваш код могут настроить ведение журнала через log4j, java.util.logging и т. Д., А ведение журнала общего доступа будет перенаправляться на этот API во время выполнения.
Распространенные претензии к ведению журнала общих ресурсов:
- Даже если вы не используете его, библиотека, от которой вы зависите, может, поэтому вам все равно придется включить ее в свой путь к классам.
- Запускает алгоритм обнаружения для каждого загрузчика классов, в который вы хотите войти, что может привести к нежелательным результатам , поэтому убедитесь, что вы поместили commons-logging.jar в правильный загрузчик классов.
- Более сложная, чем основная структура ведения журнала.
- Меньше функций, которые лежат в основе структуры ведения журнала.
Предполагаемая большая сложность, а также непредсказуемость сложных иерархий путей к классам без каких-либо предполагаемых преимуществ вызывают беспокойство у пользователей обычного ведения журналов.Также, учитывая, что этот выбор может быть навязан вам, это не вызывает у пользователей сочувствия. См. В этой статье убедительный аргумент против использования общего журнала.
Commons Logging содержит логику для определения во время выполнения, следует ли использовать log4j или java.util.logging. *.
Раньше этот код был серьезно взломан, по сути, работал только с JUL.
Основываясь на опыте с этим, был написан slf4j, который использует статическое связывание (или использовалось, я не уверен, с версией 1.6), чтобы выбрать подходящую структуру для использования log4j, JUL или логбэка вилки log4j (и т. Д.), и он включает мост, позволяющий существующему коду Commons Logging прозрачно использовать slf4j.
Если можете, используйте slf4j.