Реализация SLF4J в приложении с множеством транзитивных зависимостей - PullRequest
Новая
       13

Реализация SLF4J в приложении с множеством транзитивных зависимостей

3 голосов
/ 17 июня 2019

Я нахожусь в процессе рефакторинга веб-приложения Java, которое имеет довольно большое количество зависимостей. Я хотел бы использовать slf4j, с log4j2 в качестве базовой реализации ведения журнала. Тем не менее, приложение включает в себя некоторые зависимости Spring. Spring использует JCL (Jakarta common logging) для своей регистрации, поэтому он вводит commons-logging в качестве транзитивной зависимости. Это потенциальная проблема, потому что это означает, что slf4j может выбрать jcl в качестве реализации ведения журнала, и что Spring может войти где-то нежелательным образом.

Из документации slf4j решение состоит в том, чтобы сначала отключить commons-logging, исключив его из POM, а затем использовать jcl-over-slf4j для замены commons-logging. Конечно, jcl-over-slf4j перенаправит все предыдущие вызовы журнала, сделанные Spring, на slf4j.

Я пытался исключить commons-logging, например, 

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Однако, при проверке дерева зависимостей Maven, commons-logging все равно теперь обнаруживается как зависимость json-lib, еще одна зависимость, которая есть у проекта.

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

<dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <scope>provided</scope>
</dependency>

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

Как лучше всего исключать нежелательные зависимости ведения журнала для настройки slf4j в приложении Java?

1 Ответ

1 голос
/ 18 июня 2019

Ведение журнала Commons не является реализацией slf4j. Просто оставьте его в пути к классам и включите Log4J-Jcl для маршрутизации всех вызовов регистрации общего достояния в Log4J.

...