Редактор | Orange Jun
Произведено | Alibaba New Retail Tao Technology
основное введение
В мире java существует множество инструментов для реализации лог-функций, самый ранний широко используемый — log4j, а сейчас более популярный — slf4j+logback. Как разработчикам, нам иногда нужно инкапсулировать некоторые компоненты (сторонние пакеты) для использования другими людьми, но с таким количеством инструментов ведения журнала невозможно гарантировать, что согласованные инструменты ведения журнала могут использоваться в каждом компоненте, а их много. Подробнее Сторонний пакет, призрак знает, какой инструмент ведения журнала он будет использовать. Если приложение использует два компонента, и эти два компонента используют разные инструменты ведения журнала, то приложение будет иметь два вывода журнала, что является занозой в заднице. . Ниже приводится краткое введение в общие инструменты ведения журнала:
JUL
Полное имя JUL — java.util.logging.Logger, система ведения журналов, поставляемая с JDK, которая существует начиная с JDK1.4. Из-за существования log4j этот логгер молчал, на самом деле в каком-то тестовом коде логгер, идущий в комплекте с jdk, удобнее, чем log4j. JUL поставляется со своей собственной конкретной реализацией, похожей на log4j, logback и т. д., а не с инкапсуляцией интерфейса журнала, такой как JCL и slf4j.
import java.util.logging.Level;
import java.util.logging.Logger;
private static final Logger LOGGER = Logger.getLogger(MyClass.class.getName());
1. Глобально существует только один объект Logger с таким же именем; 2. Регистраторы обычно именуются с использованием иерархического пространства имен, разделенного точками.Имена регистраторов могут быть произвольными строками, но обычно они должны основываться на имени пакета или имени класса регистрируемого компонента, например java.net или javax.swing; 3. В файле конфигурации по умолчанию используется jre/lib/logging.properties, а уровень журнала по умолчанию — INFO; Системный файл по умолчанию можно переопределить, указав путь через системное свойство java.util.logging.config.file; 4. Уровни журнала от высокого к низкому: SEVERE (серьезный), WARNING (предупреждение), INFO (информация), CONFIG (конфигурация), FINE (подробный), FINER (более подробный), FINEST (очень подробный). Есть также два глобальных переключателя: OFF «отключает ведение журнала» и ALL «включает ведение журнала всех сообщений». 5. В файле «logging.properties» уровень журнала по умолчанию может управляться .level= ALL или на основе иерархического пространства имен. предпочтительнее, уровень журнала распознает только прописные буквы ; 6. JUL завершает фактический вывод журнала через обработчик.Один или несколько обработчиков могут быть указаны через файл конфигурации, а несколько обработчиков разделяются запятыми; также существует уровень журнала обработчика, который является самым низким уровнем журналов, которые обработчик может получать Низкий Для журналов этого уровня фактический вывод производиться не будет, к обработчику можно привязать средство форматирования журнала, например, java.util.logging.ConsoleHandler поддерживается String.format;
Пример файла конфигурации:
handlers= java.util.logging.ConsoleHandler
.level= ALL
com.suian.logger.jul.xxx.level = CONFIG
com.suian.logger.jul.xxx.demo2.level = FINE
com.suian.logger.jul.xxx.demo3.level = FINER
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=%1$tF %1$tT [%4$s] %3$s - %5$s %n
Apache Commons Logging
Ранее называвшийся Jakarta Commons Logging или сокращенно JCL, это общий API ведения журналов, предоставляемый Apache, который позволяет приложениям больше не полагаться на определенные инструменты реализации журналов.
Пакет commons-logging просто оборачивает некоторые другие инструменты ведения журналов, включая Log4J, Avalon LogKit, JUL и т. д., что позволяет приложению напрямую адаптировать журналы, управляемые API JCL, к соответствующим инструментам реализации журналов во время выполнения.
common-logging автоматически находит библиотеку журналов, которая фактически используется во время работы программы, с помощью механизма динамического поиска. Это отличается от slf4j, которая представляет собой настоящую библиотеку реализации журнала, которая статически связывается во время компиляции.
Классы-оболочки и простые реализации в пакете commons-logging перечислены ниже: 1. org.apache.commons.logging.impl.Jdk14Logger, адаптированный к JUL в JDK1.4; 2. org.apache.commons.logging.impl.Log4JLogger, адаптированный для Log4J; 3. org.apache.commons.logging.impl.LogKitLogger, адаптированный для avalon-Logkit; 4. org.apache.commons.logging.impl.SimpleLog, common-logging имеет собственный класс реализации журнала, который реализует интерфейс Log и выводит сообщения журнала в системный поток ошибок System.err; 5. org.apache.commons.logging.impl.NoOpLog, common-logging имеет свой класс реализации журнала, который реализует интерфейс Log, и не выполняет никаких операций в методе вывода логов;
Если введено только ведение журнала Apache Commons, привязка адаптера не выполняется через файл конфигурации «commons-logging.properties», а реализация LogFactory не переопределяется через системные свойства или SPI, по умолчанию используется java.util.logging, который поставляется с jdk. Регистратор для регистрации вывода.
JCL использует файл конфигурации commons-logging.properties, где вы можете указать, какой инструмент ведения журнала использовать. Если он не настроен, JUL будет использоваться для вывода журналов по умолчанию. Пример конфигурации:
Avalon LogKit
Avalon LogKit — это набор инструментов для высокоскоростной регистрации, используемый различными компонентами Avalon Framework, Excalibur, Cornerstone и Phoenix. Его модель следует тем же принципам, что и пакет регистрации JDK 1.4, но совместима с JDK 1.2+. Причина использования LogKit: Контекст и LogTargets.
При использовании Log4j содержимое журнала может быть только одним предложением, но с LogKit вы можете записывать множество элементов и даже записывать каждый элемент в соответствующем поле базы данных. Если вы используете Log4j для хранения журналов на различных носителях, таких как базы данных, вам необходимо использовать Appender, а LogKit уже может поддерживать различные цели хранения.
log4j
Log4j – это проект Apache с открытым исходным кодом. Используя Log4j, мы можем контролировать место назначения доставки информации журнала на консоль, файл, базу данных и т. д., мы также можем контролировать формат вывода каждого журнала; на уровне мы можем контролировать более подробно процесс генерации журнала.
Log4j имеет 7 различных уровней ведения журнала, от низкого до высокого: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF. Если конфигурация находится на уровне OFF, это означает закрытие журнала. Log4j поддерживает файлы конфигурации в двух форматах: свойства и xml. Содержит три основных компонента: Logger, appender, Layout.
SLF4J
Полное название SLF4J — The Simple Logging Facade for Java, простой фасад журнала.Это не конкретное решение для ведения журнала, но предоставляет некоторые API-интерфейсы ведения журнала Java в режиме фасада, подобно JCL. Не по теме, автор создал SLF4J для замены Jakarta Commons Logging (JCL).
Основной API, предоставляемый SLF4J, — это несколько интерфейсов и фабричный класс LoggerFactory. При использовании SLF4J вам не нужно указывать, какую именно систему ведения журнала вы собираетесь использовать в коде или файле конфигурации.Вы можете получить доступ к схеме реализации ведения журнала без изменения какой-либо конфигурации во время развертывания и привязать ее статически во время компиляции. библиотека.
При использовании SLF4J, если вам нужно использовать определенную реализацию ведения журнала, вы должны выбрать правильный набор jar-пакетов SLF4J (различные пакеты мостов). SLF4J предоставляет унифицированный интерфейс записи журнала, если он записывается в соответствии с предоставленным методом, окончательный формат журнала, уровень записи, метод вывода и т. д. реализуются конфигурацией конкретной системы журнала, поэтому систему журнала можно гибко переключается в приложении.
logback является естественной реализацией slf4j-api и может использоваться без пакета моста. Кроме того, slf4j также инкапсулирует множество других пакетов мостов, которые можно использовать в других реализациях журналов, таких как slf4j-log4j12, который может использовать log4j для низкоуровневого вывода журнала, и slf4j-jdk14, который может использовать JUL для вывода журнала.
Logback
Logback, «надежная, общая, быстрая и гибкая среда ведения журналов для Java». Logback в настоящее время разделен на три модуля: logback-core, logback-classic и logback-access. logback-core является базовым модулем для двух других модулей. logback-classic — это улучшенная версия log4j, которая полностью реализует API SLF4J.
Модуль logback-access интегрируется с контейнером сервлетов, чтобы обеспечить доступ к журналам через Http. Logback опирается на файл конфигурации logback.xml и, конечно же, поддерживает метод groovy. По сравнению с log4j у Logback много-много преимуществ, после долгих поисков в интернете я не буду здесь вдаваться в подробности.
Log4j2
Log4j 2 — это улучшенная версия log4j 1.x и logback.Говорят, что он использует некоторые новые технологии (блокировочная асинхронность и т. д.), что делает пропускную способность и производительность журналов в 10 раз выше, чем у log4j 1.x, и решает некоторые проблемы взаимоблокировки, ошибка, и конфигурация более проста и гибка.
Log4j2 поддерживает структуру подключаемых модулей, и вы можете расширить Log4j2 в соответствии с вашими потребностями, чтобы реализовать свои собственные приложения, регистраторы, фильтры и т. д. На свойства можно ссылаться в файлах конфигурации, а также их можно напрямую заменять или передавать компонентам, а также поддерживаются файлы конфигурации в формате json. В отличие от других фреймворков ведения журналов, он не теряет предыдущие файлы журналов при перенастройке.
Log4j2 использует поддержку параллелизма в Java 5 для обеспечения минимально возможного уровня блокировки. Исправлена взаимоблокировка, сохраняющаяся в log4j 1.x. Log4j 2 основан на библиотеке LMAX Disruptor. В многопоточном сценарии по сравнению с существующей платформой ведения журналов асинхронный регистратор обеспечивает повышение эффективности примерно в 10 раз.
Архитектура Log4j2:
сцены, которые будут использоваться
Просто используйте java.util.logging.Logger
В самом простом сценарии формальная система вообще так не используется.Если вы пишете небольшую демку, тест-кейс и т. д., вы можете использовать ее таким образом. Не нужны никакие сторонние зависимости, встроенная поддержка jdk.
Используйте только ведение журнала Apache Commons
Необходимо ввести пакет commons-loging. Пример выглядит следующим образом:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
Ведение журнала Apache Commons в сочетании с log4j
Необходимо представить пакеты commons-logging и log4j, например:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
API-интерфейсы Dot, которые можно использовать в этом режиме:
1. org.apache.commons.logging.Log, API в Commons-Logging; 2. org.apache.log4j.Logger, API в log4j;
Независимо от того, какой API используется, окончательный журнал проходит через log4j для фактического ведения журнала. Рекомендуется использовать API в журнале commons.Если вы используете API непосредственно в log4j, это ничем не отличается от использования только log4j, и нет необходимости вводить пакет commons-logging.
Поскольку ведение журнала в конечном итоге достигается с помощью log4j, уровень, цель и т. д. вывода журнала также контролируются с помощью файла конфигурации log4j. Ниже приведен простой пример файла конфигурации log4j «log4j.properties»:
#log4j.rootLogger = error,console
log4j.logger.com.suian.logtest = trace,console
#输出源console输出到控制台
log4j.appender.console = org.apache.log4j.ConsoleAppender
log4j.appender.console.Target = System.out
log4j.appender.console.layout = org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern = %d{yyyy-MM-dd HH:mm:ss,SSS} [%t] %-5p %c - [log4j]%m%n
Поскольку рекомендуется использовать управление API в commons-logging, чтобы найти реализацию журнала log4j, связь должна быть явно определена через файл конфигурации «commons-logging.properties». Пример выглядит следующим образом:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
Код использует API JCL для управления журналом, а log4j используется для вывода журнала на нижнем уровне. Управление выводом журнала зависит от файла конфигурации log4j, а связь привязки с log4j должна быть явно указана в файле конфигурации commons-logging.properties.
Используйте только log4j
Это было самое популярное использование в первые годы, а сейчас оно постепенно ушло с исторической сцены из-за проблем самого log4j и появления новых фреймворков для журналов. В частности, как использовать себя, чтобы перейти на Baidu.
SLF4J в сочетании с Logback
Самое популярное использование на данный момент, SLF4J — это наиболее широко используемый бревенчатый фасад, плюс естественная реализация Logback, которая проста, унифицирована и быстра.
Необходимо ввести сторонние зависимости:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
</dependency>
Использование только Log4j2
Log4j2 похож на SLF4J+Logback. log4j-api эквивалентен SLF4J, а log4j-core эквивалентен Logback.
Необходимо ввести сторонние зависимости:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.6.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.6.2</version>
</dependency>
разрешение конфликтов
Теоретически могут сосуществовать различные методы вывода журнала, такие как log4j, log4j2 и logback и т.д., но проблема в том, что нам приходится поддерживать несколько файлов конфигурации, мы должны полностью понимать, какой компонент журнала использует каждый компонент, а затем делать соответствующий Profile конфигурация.
Как это решить? Каждый, кто хочет сделать общее решение для ведения журнала, имеет специальную обработку проблем совместимости. В настоящее время только slf4j и log4j2 предоставляют такой механизм интеграции, а остальные в основном слабы. Список API управления журналами, которые можно использовать в коде:
1. java.util.logging.Logger, поставляемый с jdk; 2. org.apache.commons.logging.Log — API в пакете commons-logging; 3. org.apache.log4j.Logger, API в пакете log4j; 4. org.apache.logging.log4j.Logger, API, предоставляемый log4j2, находится в пакете log4j-api; 5. org.slf4j.Logger, API, предоставляемый slf4j, находится в пакете slf4j-api;
Вышеупомянутые методы управления могут сосуществовать в приложении.Даже если код, написанный вами, может обеспечить использование одного и того же типа API, введенные сторонние зависимости могут быть различными. Как с этим бороться?
Как упоминалось ранее, slf4j и log4j2 теперь могут поддерживать различные конфликты на месте, и оба они предоставляют множество связующих и мостов.
1. Так называемый биндер, который также можно назвать адаптером или классом-оболочкой, предназначен для привязки логов конкретного API к конкретному компоненту реализации лога для вывода. Например, JCL можно связать с выводом log4j или JUL, другим примером является slf4j, который можно вывести через logback или с log4j, log4j2, JUL и т. д.; 2. Так называемый бридж - это инструмент реализации поддельного лога.Например, когда вы кладете jcl-over-slf4j.jar в CLASS_PATH, даже если компонент изначально выводил логи через JCL, теперь он будет jcl-over-slf4j" чит" в SLF4J, а затем SLF4J передаст журнал конкретному инструменту реализации журнала в соответствии с компоновщиком.
slf4j интегрированный вывод журнала
java.util.logging.Logger
Чтобы интегрировать журналы JUL в унифицированный вывод slf4j, вам необходимо импортировать пакет зависимостей, предоставленный slf4j:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.22</version>
</dependency>
Только введение зависимостей не может интегрировать журналы JUL.Пакет предоставляет только обработчик JUL, который все еще необходимо настроить с помощью файла конфигурации JUL.Уровень журнала, установленный в связывателе slf4j (например, logback), эквивалентен уровню обработчика JUL. Уровень журнала, поэтому для управления выводом журнала JUL уровень журнала по-прежнему контролируется в двух местах: в файле конфигурации JUL «logging.properties» и в файле конфигурации связующего slf4j, например «logback.xml», «log4j2». .xml" и т. д.
1. Создайте файл конфигурации jdk14-logger «logger.properties», добавьте конфигурацию обработчика и конфигурацию уровня журнала;
handlers= org.slf4j.bridge.SLF4JBridgeHandler
.level= ALL
Добавьте параметр конфигурации JVM -Djava.util.logging.config.file=/path/logger.properties при запуске программы или контейнера, конечно, можно использовать и программную обработку, можно использовать метод main или расширить слушатель контейнер как система Инициализация завершена, в некоторых сценариях этот метод не такой тщательный, как настройка параметров JVM.Например, если вы хотите проксировать системный выходной журнал tomcat, метод программирования не может быть выполнен.
org.apache.commons.logging.Log
Чтобы интегрировать журналы JCL в унифицированный вывод slf4j, вам необходимо импортировать пакет зависимостей, предоставленный slf4j:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.22</version>
</dependency>
Корневой путь всех классов в пакете jcl-over-slf4j — org.apache.commons.logging, а также существуют классы Log и LogFactory, которые эквивалентны соединению JCL за счет перезаписи пакета commons-logging. Log точно такой же, как и в пакете commons-logging.Реализация LogFactory — org.apache.commons.logging.impl.SLF4JLogFactory.
Пакет commons-logging по умолчанию использует org.apache.commons.logging.impl.LogFactoryImpl. Реализация моста по такой цене может обеспечить плавную стыковку, в отличие от JUL, который должен добавить дополнительную конфигурацию, но одним недостатком является то, что он должен иметь дело с конфликтами библиотек классов. Пакет commons-logging и пакет jcl-over-slf4j не должны сосуществовать, а пакет commons-logging необходимо исключить из пути к классам.
Не по теме, поскольку сам JCL поддерживает привязку адаптеров через конфигурационный файл «commons-logging.properties», лично я склонен инкапсулировать адаптер для его поддержки, точно так же, как org.apache.commons в пакете commons-logging.logging. impl.Log4JLogger, это больше соответствует мышлению программиста, ясно.
Именование пакета моста также очень специфично: перезаписанный пакет называется xxx-over-slf4j, например jcl-over-slf4j в этом примере; чистый мост называется xxx-to-slf4j, как упоминалось ранее в статье. , jul-to-slf4j.
▐ org.apache.log4j.Logger
Чтобы интегрировать журналы log4j в унифицированный вывод slf4j, вам необходимо импортировать пакет зависимостей, предоставленный slf4j:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.22</version>
</dependency>
Просто посмотрите на название пакета моста, log4j-over-slf4j должен перезаписать пакет log4j:log4j, поэтому вам нужно только ввести зависимости для его использования, и никакой другой дополнительной настройки не требуется. Но бороться с конфликтами все же необходимо.Пакет log4j и log4j-over-slf4j не могут сосуществовать.
org.apache.logging.log4j.Logger
Интегрируйте журналы log4j2 в унифицированный вывод slf4j, slf4j не предоставляет пакет моста, но log4j2 предоставляет, принцип тот же, сначала введите пакет моста log4j2:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-to-slf4j</artifactId>
<version>2.6.2</version>
</dependency>
Log4j2 поставляется с org.apache.logging.log4j: log4j-api и org.apache.logging.log4j: log4j-core, его роль ясна. Log4j-core — стандартная реализация log4j-API, и тот же log4j-to-SLF4J — тоже реализация Log4j-API.
log4j-to-slf4j используется для соединения журналов, выводимых log4j2 с slf4j для фактического вывода.Функционально log4j-core и log4j-to-slf4j не могут сосуществовать, потому что будет две реализации log4j2.
После теста, по анализу результатов теста проблем с сосуществованием нет, какое решение? Когда log4j2 загружает провайдеров, используется приоритетная стратегия, и даже если найдено несколько провайдеров, можно определить доступного провайдера. Во всех зависимых пакетах, обеспечивающих реализацию log4j2, есть конфигурационный файл META-INF/log4j-provider.properties, в нем свойство FactoryPriority используется для настройки приоритета провайдера, благо у log4j-to-slf4j(15) приоритет выше чем log4j-core (10), поэтому результаты теста соответствуют ожиданиям, а журнал log4j2 подключается к slf4j для вывода.
Точно так же, чтобы обеспечить надежность системы, рекомендуется исключить log4j-core из пути к классам, и log4j2 также рекомендует это сделать.
log4j2 интегрированный вывод журнала
java.util.logging.Logger
Чтобы интегрировать журналы JUL в унифицированный вывод log4j2, вам необходимо импортировать пакет зависимостей, предоставленный log4j2:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jul</artifactId>
<version>2.6.2</version>
</dependency>
Способ, которым log4j2 интегрирует журналы JUL, отличается от slf4j. slf4j определяет только обработчик и по-прежнему зависит от файла конфигурации JUL; log4j2 напрямую наследует и перезаписывает java.util.logging.LogManager.
При использовании нужно только привязать переписанный LogManager (org.apache.logging.log4j.jul.LogManager) через системное свойство java.util.logging.manager, что гораздо проще метода slf4j.
org.apache.commons.logging.Log
Чтобы интегрировать журналы JCL в унифицированный вывод log4j2, вам необходимо импортировать пакет зависимостей, предоставленный log4j2:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>2.6.2</version>
</dependency>
Интегрировать JCL на основе пакета log4j-jcl относительно просто, если пакет log4j-jcl добавлен в путь к классам. Кажется, что метод интеграции slf4j намного элегантнее.Основной принцип заключается в следующем: когда JCL LogFactory инициализируется, он ищет конкретную реализацию LogFactory, которая разделена на несколько сценариев, которые кратко описаны следующим образом. :
Сначала найдите класс реализации LogFactory в соответствии с системным свойством org.apache.commons.logging.LogFactory; Если он не найден, класс реализации ищется в режиме SPI, META-INF/services/org.apache.commons.logging.LogFactory; таким образом поддерживается log4j-jcl; этот способ должен гарантировать, что все приложение, включая В стороннем пакете jar, от которого зависит приложение, есть только один файл org.apache.commons.logging.LogFactory.Если файлов несколько, то приоритет имеет тот, который загружается первым. Если есть конфликт, его также очень хлопотно расследовать. Если он по-прежнему не найден, прочтите файл конфигурации «commons-logging.properties» и используйте класс реализации LogFactory, указанный в свойстве org.apache.commons.logging.LogFactory; Наконец, если вы не можете его найти, используйте реализацию по умолчанию org.apache.commons.logging.impl.LogFactoryImpl.
org.apache.log4j.Logger
Чтобы интегрировать журналы log4j 1.x в унифицированный вывод log4j2, вам необходимо импортировать пакет зависимостей, предоставленный log4j2:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<version>2.6.2</version>
</dependency>
Интеграция журналов log4j 1.x в log4j2 также достигается за счет перезаписи API log4j 1.x, что согласуется с принципом реализации slf4j. Следовательно, возникает проблема конфликта библиотек классов.Если используется log4j-1.2-api, все пакеты log4j 1.x в пути к классам должны быть очищены.
org.slf4j.Logger
Чтобы интегрировать журналы slf4j в унифицированный вывод log4j2, вам необходимо импортировать пакет зависимостей, предоставленный log4j2:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.6.2</version>
</dependency>
log4j-slf4j-impl реализует интерфейс slf4j на основе log4j2, который является мостом между slf4j-api и log4j2-core. Здесь есть проблема, на которую стоит обратить внимание: убедитесь, что log4j-slf4j-impl и log4j-to-slf4j не сосуществуют в пути к классам, иначе события будут бесконечно маршрутизироваться между SLF4J и Log4j2.
Реализация привязки API управления журналами
И slf4j-api, и log4j-api являются интерфейсами и не предоставляют конкретных реализаций.Теоретически журналы, выводимые этими двумя API, могут быть привязаны ко многим реализациям журналов. slf4j и log4j2 также предоставляют множество связующих. Вот несколько возможных цепочек связывания:
slf4j → журнал
slf4j → slf4j-log4j12 → log4j
slf4j → log4j-slf4j-импл → log4j2
slf4j → slf4j-jdk14 → июль
slf4j → slf4j-jcl → jcl
jcl → июль
jcl → log4j
log4j2-api → log4j2-cor
log4j2-api → log4j-to-slf4j → slf4j
Приходите к кольцевой диаграмме:
Группа Hand Amoy Industry и Intelligent Operation Team
В Ali, если вы не сталкиваетесь с электронной коммерцией, вы можете потерять половину удовольствия от работы; в электронной коммерции, если вы не занимаетесь бизнес-аналитикой, вы можете потерять связи с людьми, товарами, рынками и предприятия, создавая сотни миллионов пользователей.Возможность для лучшей жизни! Но теперь перед вами работа, полная веселья и возможностей - это отраслевая и интеллектуальная операционная команда, самая интеллектуальная техническая команда в электронной коммерции! Все уже прошли, не пропустите! Мы хотим построить команду с сильным чувством счастья сверху донизу - если вы ищете счастья, приходите к нам, нет проблем! Будущее наступило.Дао - это отраслевая и интеллектуальная рабочая команда технологического отдела.Эта команда собирается стать самой счастливой технической командой в Alibaba.Мы с нетерпением ждем вашего любопытства и мыслительных способностей, чтобы присоединиться к нам!
В настоящее время, Alibaba Сямэнь Департамента Министерства промышленности и технологий разведывательной группы, инженеры Java, технологи, архитекторы для сообщества + вербовка кампуса, база Ханчжоу Xixi парк Али-Баба!
Отправьте нам свое резюме: mingkai.wmk@alibaba-inc.com