java.lang.NoClassDefFoundError_ org_springframework_boot_bind_RelaxedPropertyResolver

例外の問題:

まず問題を見てみましょう。今日、druid を使用したプロジェクトを新しいプロジェクトにコピーしようとしましたが、この問題は不可解に発生しました。非常に奇妙です。

java.lang.NoClassDefFoundError: org/springframework/boot/bind/RelaxedPropertyResolver
	at org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.getExcludeAutoConfigurationsProperty(AutoConfigurationImportSelector.java:205) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]
	at org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.getExclusions(AutoConfigurationImportSelector.java:199) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]
	at org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.selectImports(AutoConfigurationImportSelector.java:96) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]
	at org.springframework.context.annotation.ConfigurationClassParser$DefaultDeferredImportSelectorGroup.process(ConfigurationClassParser.java:888) ~[spring-context-5.2.2.RELEASE.jar:5.2.2.RELEASE]
	at org.springframework.context.annotation.ConfigurationClassParser$DeferredImportSelectorGrouping.getImports(ConfigurationClassParser.java:874) ~[spring-context-5.2.2.RELEASE.jar:5.2.2.RELEASE]

047DF42F.gif

そこでオンラインで確認したところ、依存関係の競合があることがわかりました。オンラインでの解決策のほとんどは、親プロジェクトを継承することでした。

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.1.7.RELEASE</version>
</parent>

はい、追加すると便利です。しかし、いつも奇妙に感じます。問題が 2 つあります。
04951572.gif

問題について考える

  1. 以前のプロジェクトの開始に問題がなかったのはなぜですか?
  2. この方法は症状を治療するものですが、根本的な原因を治療するものではないと常々感じています。遺伝を望まない場合はどうすればよいでしょうか。

問題 1 を解決する

したがって、問題を念頭に置いて情報を調べ始めたとき、それは依存関係の競合にすぎず、解決する必要があるだけでした。
まず、競合する依存関係を見つけます。どうやって見つけるのですか? 質問に対する答えは
画像.png
明白です。この jar パッケージにはそのようなクラスはありません。
したがって、まずこの jar パッケージを見つけて
画像.png
チェックしてください。実際、そのような jar パッケージは 2 つあります。2 つのバージョンには互換性がないだけです。経験に基づいて、jar パッケージの上位バージョンにはこのクラスが必要だと思います (実際には、確認したところ、古いプロジェクトでは 2.2.2.RELEASE) の jar パッケージしか導入されていなかった
ため、問題が判明したため、1.5.22.RELEASE の依存関係を見つけて、この jar パッケージを除外してください。
依存関係の検索も非常に簡単です
画像.png
画像.png
. ツールは競合についても説明しています.
druid-spring-boot-starter が導入されると、jar パッケージが競合することは明らかです. 誰がバージョンを小さくしたのか、それを削除するだけです.
画像.png
競合するjarパッケージの競合を解消した後、プロジェクトを開始します。

問題 2 を解決する

ブロガーは不運です。まだ問題があるので
画像.png
検索しました。解決策は、jdbc への依存関係を追加することです。

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>5.2.4.RELEASE</version>
</dependency>

試してみると、確かに問題は解決しました。ふふ、それならわかりました。それでも独自の jar パッケージに依存するのは問題なので、依存ライブラリを確認したところ、mybatis-spring-boot- に jdbc のバージョンがあったことがわかりました
。スターターが低すぎたので、依存関係を
最新バージョンにアップグレードして
画像.png
からプロジェクトを開始し
画像.png
、美しく完璧に開始します。
04973B8E.jpg
これは私が信頼している構成です。参考にしてください。

 <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>2.2.2.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <version>2.2.2.RELEASE</version>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <artifactId>spring-boot-autoconfigure</artifactId>
                    <groupId>org.springframework.boot</groupId>
                </exclusion>
            </exclusions>
        </dependency>
        <!--springboot+mybatis的依赖-->
        <dependency>
            <groupId>org.mybatis.spring.boot</groupId>
            <artifactId>mybatis-spring-boot-starter</artifactId>
            <version>2.1.2</version>
        </dependency>
<!--        <dependency>-->
<!--            <groupId>org.springframework</groupId>-->
<!--            <artifactId>spring-jdbc</artifactId>-->
<!--            <version>5.2.4.RELEASE</version>-->
<!--        </dependency>-->
        <!--MySQL数据库驱动-->
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.19</version>
        </dependency>
        <!--Lombok依赖(可以配置也可以不用配置具体看自己)-->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.16.18</version>
        </dependency>
        <!--fastjson-->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>2.0.24</version>
        </dependency>
        <!--druid数据源-->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid</artifactId>
            <version>1.2.1</version>
        </dependency>
        <!--druid数据库连接池依赖-->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid-spring-boot-starter</artifactId>
            <version>1.2.18</version>
            <exclusions>
                <exclusion>
                    <artifactId>spring-boot-autoconfigure</artifactId>
                    <groupId>org.springframework.boot</groupId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.8.0-beta4</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-nop</artifactId>
            <version>1.7.2</version>
            <type>jar</type>
        </dependency>
    </dependencies>

この投稿が皆様のお役に立てば幸いです

補充する

ところで、別の質問があります: なぜ私の古いプロジェクトはうまく機能するのでしょうか? その理由は、依存関係の競合がある場合、Maven の解決策は次のようになります: たとえば、次の 2 つの依存関係があります

A -> B -> C -> D(V1)
F -> G -> D(V2)

この時点で、D の 2 つのバージョンがプロジェクトに表示されます。このとき、Maven は最短パスの原則を採用し、D の V2 バージョンを選択します。これは、D の V1 バージョンが間接的に A パッケージに依存し、依存関係全体に依存しているためです。パスの長さは 3 ですが、V2 バージョン D はパッケージ F に間接的に依存しており、依存関係パス全体の長さは 2 です。
次のような 2 つの依存関係があるとします。

A -> B -> D(V1)
F -> G -> D(V2)

このとき、D の 2 つのバージョンの依存関係パスは同じ長さであるため、最短パスの原則は失敗します。このときの Maven の解決策は、pom.xml で依存パッケージが宣言されている順序に従って、最初に宣言されたパッケージを優先するというもので、
私は 2 番目のタイプに属します。
参考:https://blog.csdn.net/WinWill2012/article/details/71717811

おすすめ

転載: blog.csdn.net/weixin_40741732/article/details/131088598