Не удалось запустить загрузочный сервер spring

Ответ 1

Исключение logback-classic из spring -boot-starter-web и spring -boot-starter-actuator работало я

compile("org.springframework.boot:spring-boot-starter-web:1.1.10.RELEASE") {
    exclude module: "spring-boot-starter-tomcat"
    exclude module: "spring-boot-starter-logging"
    exclude module: "logback-classic"
}
compile("org.springframework.boot:spring-boot-starter-actuator:1.1.10.RELEASE") {
    exclude module: "logback-classic"
}

Ответ 2

Добавьте это в свой build.gradle

configurations.all {
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
        exclude group: 'org.springframework.boot', module: 'logback-classic'
}

Ответ 3

В моем проекте используется

• spring boot 1.4.2.RELEASE
• оба slf4j 1.7.21 и logback 1.1.7. (некоторая зависимость, называемая модулем A, зависит от logback 1.1.2, это проблема)

Сначала Введение в механизм зависимостей

Согласование зависимостей - это определяет, какая версия зависимости будет использоваться при обнаружении нескольких версий артефакта. В настоящее время Maven 2.0 поддерживает только "ближайшее определение", что означает, что он будет использовать версию ближайшей зависимости от вашего проекта в дереве зависимостей. Вы всегда можете гарантировать версию, объявив ее явно в своем проекте POM. Обратите внимание: если две версии зависимостей находятся на одной и той же глубине в дереве зависимостей, пока Maven 2.0.8 не будет определен, какой из них будет побежден, но поскольку Maven 2.0.9 это порядок в объявлении, который считается: первое объявление выигрывает. "ближайшее определение" означает, что используемая версия будет самой близкой к вашему проекту в дереве зависимостей, например. если зависимости для A, B и C определены как A → B → C → D 2.0 и A → E → D 1.0, тогда D 1.0 будет использоваться при построении A, поскольку путь от A до D через E короче. Вы можете явно добавить зависимость к D 2.0 в A, чтобы принудительно использовать D 2.0

Итак, maven будет использовать logback 1.1.7 в моем проекте. Я не уверен, что это мой модуль A, несовместимый с 1.1.7 или logback 1.1.7, несовместимый с slf4j 1.7.21 Что бы ни случилось, в моем случае. Я добавляю dependencyManagement в мой pom. Скажите maven использовать lockback 1.1.2 только. Проблема решена.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>1.1.2</version>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-core</artifactId>
            <version>1.1.2</version>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-access</artifactId>
            <version>1.1.2</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Ответ 4

Gradle решение добавляет ниже строки в build.gradle:

configurations {
    all*.exclude module : 'spring-boot-starter-logging'
}

Ответ 5

для моего файла gradle.build для меня работала следующая конфигурация:

configurations {
    all*.exclude group: "org.springframework.boot", module: "spring-boot-starter-logging"
    all*.exclude group: "ch.qos.logback"
    all*.exclude group: "org.slf4j", module: "log4j-over-slf4j" // allow using log4j 2.x
    all*.exclude group: "org.slf4j", module: "slf4j-simple"     // log4j is the configured backend
}

Ответ 6

Я бы порекомендовал вам попробовать удалить любую зависимость, содержащую Logback, наиболее распространенный из них:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>

Это сработало для меня.

Ответ 7

Наконец, разрешив эту проблему, исключив зависимость от журнала и явно добавляя зависимость log4j