これは、新しいアプリケーションを行う方法です。さまざまな問題に遭遇します。昨日、特定のクラスをロードするときにクラスローダーからクラスの問題が表示されないことを解決しました。今日、私は第二党のライブラリに関連するログファイルを見つけられないという問題に遭遇しました。それについて一つずつ話しましょう。
通常の状況では、以下の図に示すように、SRC/Main/Resources Directory（Logbackログシステムを使用）のLogback-spring.xml構成ファイルを置きます（ログバックログシステムを使用）
spring.application.name = spring-boot-demo-application in application.Propertiesを設定します
2パーティのパッケージには、logback.xmlが含まれています
上記の構成によれば、実行後、通常の状況では、application.logログファイルがuser.home.home/spring-boot-demo-application/logsディレクトリに含まれることを願っていますが、そうではありません。 Spring-Boot-Demo-Applicationフォルダーも生成されていません。
ログシステムがログ構成ファイルをどのように見つけて解析するかを見てみましょう。 Springbootは、LoggingApplicationListenerクラスを使用して、ログシステムを初期化します。 LoggingApplicationListenerは、ApplicationListenerインターフェイスを実装します。次に、LoggingApplicationListenerのOnApplicationEventメソッドがタイミングチャートを使用して行うことを確認できます。
コード（8）標準のログ構成ファイルを見つけます。標準は何ですか？次に、コードコード（9）を見てください。
protected string [] getStandardConfiglocations（）{return new String [] {"logback-test.groovy"、 "logbacktest.xml"、 "logback.groovy"、 "logback.xml"}; }「logback-test.groovy」、「logbacktest.xml」、「logback.groovy」、「logback.xml」などが標準です。
したがって、それを見つける方法はコード（10）に依存します。
private string findconfig（string [] locations）{for（string location：locations）{classPathResource resource = new ClassPathResource（location、this.classloader）; if（resource.exists（））{return "classpath：" + location; }} nullを返します。 }ClassPathResourceクラスを使用して検索することがわかります。ClassPathResourceの存在する方法を見てみましょう。
public boolean existes（）{return（resolveurl（）！= null）; } protected url resolveurl（）{if（this.clazz！= null）{return this.clazz.getResource（this.path）; } else if（this.classloader！= null）{return this.classloader.getResource（this.path）; } else {return classloader.getSystemResource（this.path）; }}this.classloader.getResource（this.path）;クラスローダーをAppClassLoaderとして見つける。
コード（8）が構成を見つけられない場合、実行ポイント（12）。ロジックとコード（8）は似ていますが、ファイル名は異なります。見てみましょう：
protected string [] getSpringConfiglocations（）{string [] locations = getStandardConfiglocations（）; for（int i = 0; i <locations.length; i ++）{string endix = stringutils.getFileNameExtension（locations [i]）;場所[i] =場所[i] .substring（0、locations [i] .length（） - endix.length（） - 1） + "-spring。" +拡張子; }場所を返します。 }SpringがgetStandardConfiglocationsのファイル名にスプライスされていることがわかります。スプライスされたファイル名は次のとおりです。
「「logback-test-spring.groovy」、「logback-test-spring.xml」、「logback-spring.groovy」、「logback-spring.xml」
要約すると、Springbootは標準のログ構成ファイルを最初に検索します。 Splices Spring構成のファイルが見つからない場合。
そのため、上記のlogback.xmlを含むJARパッケージがアプリケーションに導入され、このJARパッケージはAppClassLoaderを使用してロードされていると述べました。したがって、ステップ（8）を実行すると、JARパッケージのlogback.xmlが見つかりました。そのため、ステップ（12）を実行してカスタマイズされたlogback-spring.xmlを見つけません。
ソリューション1：構成ファイルをlogback.xmlに変更します。これにより、ステップ（8）で、最初にlogback.xmlを探します。
ソリューション2：logback.xmlを含む2パーティパッケージを避けます。この場合、独自の構成がlogback-spring.xmlまたはlogback.xmlであるかどうかに問題はありません。
毎日の開発では、セカンドパーティパッケージにログ構成ファイルを含めるべきではありません。第2パーティライブラリで使用されるログは、通常、コードを使用して作成されます。
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。