包括的な実際の戦闘
この章では、Spring Bootの外部構成の原理とソースコード分析について説明します。このセクションでは、特定の例を使用して、SpringBootでさまざまなタイプのパラメーターと構成を使用する方法を簡単に示します。また、このセクションの例に含まれるいくつかの新しい知識ポイントを簡単に紹介し、拡張します。
このセクションの例では、コマンドラインを使用してパラメーター、デフォルトの構成ファイルapplication.properties、プロファイル構成パラメーター、パラメーターを取得するための@Valueアノテーション、およびタイプセーフな@ConfigurationPropertiesアノテーション関連のBean関数を渡します。
Spring Bootは外部化構成を簡素化したため、前の章の関連する原則の紹介に従って、実際に使用すると非常に便利です。ここで、標準のSpringBootプロジェクトを作成しました。バージョンは2.2.1.RELEASEです。まず、プロジェクトのディレクトリ構造を確認します。
pom.xmlで導入されたコア依存関係はspring-boot-starter-webであり、対応する依存関係のソースコードは次のとおりです。
<依存関係> <groupId> org。春のフレームワーク。ブート</ groupId> <artifactId> spring- boot- starter-web </ artifactId> </依存関係>
SpringbootConfigApplicationクラスはSpringBootプロジェクトのスタートアップクラスであり、あまり紹介しません。
ConfigControllerクラスは、リクエストを受信するコントローラーです。デフォルトのgetConfigParamsメソッドを定義します。さまざまな方法で取得されたパラメーター値が、このメソッドに出力されます。関連するソースコードは次のとおりです。
@RestController
public class ConfigController {
@Value（ "$ {user .username}"）
private String username;
@Value（ "$ {user .password}"）
プライベート文字列パスワード;
@Resource
private LoginUserConfig loginUserConfig;
@Value（ "$ {projectName：unknown}"）
private String projectName;
@RequestMapping（ "/"）
public String getConfigParams（）{
//启PINコマンドMOSFET递参数
システム。でる 。println（ "Command config projectName：" + projectName）; //通超過アプリケーション配置文件配置的参数
システム。でる 。println（ "Application config Username
System .out .println（" Application config Password：” + password）;
// @ ConfigurationPropertiesアノテーションを介して構成されたパラメーター
System .out .println（ "
UserConfig
.getUsername（））;
System .out .println（ "Configurat ionProperties config Password：” + login
UserConfig .getPassword
（））;
戻る "";
}
@RestControllerアノテーションは、このクラスを、要求を受信してインスタンス化できるコントローラーとして指定するために使用されます。このクラス内では、さまざまな方法で設定されたパラメーターが@Valueアノテーションと@Resourceアノテーションを介して取得されます。getConfigParamsメソッドを介して外部アクセス要求を提供します。要求を受信すると、パラメーター値を取得するためのさまざまな方法が出力されます。
まず、@ Valueで取得した値のソースを見てみましょう。この例では、対応する値を設定する方法が2つあります。
application.properties構成ファイルとコマンドラインパラメーター。
コマンドラインパラメータについては、コマンド実行時に「a name = value」の形式でコマンドを渡すのが基本的な転送方法であることはすでに述べましたが、例を組み合わせると次のようになります。
java -jarspringboot-config-0。0.1-スナップショット。jar --projectName = SpringBoot
ConfigControllerクラスでは、@ Valueの基本形式は@Value（ "$ {param}"）であることがわかりますが、コマンドラインパラメーターの取得には@Value（ "$ {param：default}"）を使用します。 。実際には、これら2つの方法が一般的に使用され、2つ目は、デフォルト値をコロン区切り文字で渡す方法です。paramパラメーターが存在しないか、アプリケーションで構成されていない場合は、指定されたデフォルト値が使用されます。
現在の例を例にとると、startupコマンドでprojectNameパラメーターが指定されておらず、@ Valueの取得時にデフォルト値「unknown」が指定されていない場合、startupコマンドを実行すると例外がスローされ、起動を開始できません。これは、@ Valueを使用するときに注意する必要がある状況です。
application.properties構成ファイルでのパラメーターの設定が簡単な場合は、対応するファイルに対応するkey = value値を直接設定するだけです。たとえば、この例のapplication.propertiesの構成ソースコードは次のとおりです。
＃パブリック構成、すべての環境で8080 サーバーの 使用が開始されます。port=8080spring。profiles。active = dev
しかし、実際の過程で、環境ごとに異なる構成ファイルが必要になる場合がよくあります。構成ファイルを変更したり、環境を変更するたびに再パッケージしたりすると、面倒になります。現時点では、付属のSpringBootを使用できます。問題を解決するためのプロファイル構成機能。この例で提供されている3つのプロパティ構成ファイルは、プロファイル構成の基本的な使用法を示すためのものです。
通常の状況では、環境に応じて1つ以上のプロパティ構成ファイルがプロジェクトに作成されます。通常の状況では、対応する命名形式と関連する機能は次のとおりです。
- * applcation.properties：パブリック構成。
- * application-dev.properties：開発環境の構成。
- .application-test.properties：テスト環境の構成。
- application-prod.properties：実稼働環境の構成。
もちろん、名前付けの「dev」テストと「prod」はカスタマイズでき、これらの構成をいつ使用するかは、application.properties構成ファイルのspring.profiles.activeパラメーターをアクティブにすることで制御できます。
たとえば、applcation.propertiesでパブリック構成を実行してから、次の構成を使用して、指定された環境の構成をアクティブ化します。
春。profiles.active = prod
その中で、「prod」はファイル名のapplication-prod.propertiesと比較されます。Spring Bootは、処理中に構成ファイルapplcation.propertiesを取得し、指定されたプロファイル値「prod」を使用してスプライシングを行い、application-prod.propertiesファイルの名前とパスを取得します。ロードとスプライシングの特定の手順と原則については前の章で説明したので、例を使用してそれらを確認できます。
上記の例では、dev構成環境をアクティブ化しており、application-dev.propertiesの構成は次のとおりです。
＃テスト環境のユーザー名とアカウント ユーザー。username = test-admin ユーザー。password = test-pwd
このとき、対応するリクエストにアクセスすることにより、getConfigParamsメソッドの印刷に対応するログは次のようになります。
アプリケーション構成 ユーザー名：test- admin アプリケーション構成パスワード：test-pwd
実稼働環境の構成をアクティブ化する場合は、application.propertiesでspring.profiles。active= prodを構成するだけで済みます。
@Valueパラメータ値の取得とプロファイルベースのパラメータ設定が大幅に拡大しました。@ Valueの使用には、通常の文字列、オペレーティングシステム属性、式の結果、ファイルリソース、URLリソースなどの挿入も含まれます。公式ドキュメントを参照できます。関連する例を用いたさらなる研究。
上記の@Valueの使用では、単一の属性を挿入して構成できますが、構成属性が多数ある場合、または構成属性自体が階層構造になっている場合は、便利で柔軟性がありません。したがって、SpringBooはタイプセーフな構成方法を提供します。
ConfigControllerでは、@ Resourceを介してLoginUserConfigクラスを挿入します。このクラスは、@ ConfigurationPropertiesアノテーションを介してプロパティをLoginUserConfigのプロパティに関連付け、タイプセーフティ構成を実現します。LoginUserConfigのソースコードは次のとおりです。
@ Component @ ConfigurationProperties（prefix = "user"）
public class LoginUserConfig {
private String username;
プライベート文字列パスワード。
//省略ゲッター/セッターメソッド
}
LoginUserConfigクラスのソースコードで、@ ConfigurationPropertiesアノテーションは、ユーザーのプレフィックスが付いた構成プロパティがインスタンス化中にLoginUserConfigクラスの対応するプロパティにバインドされ、クラスが@Componentによってインスタンス化されることを指定します。
ここで、指定された構成ファイルはdevであるため、上記のdev構成ファイルのuser.usernameとuser.passwordの値は、それぞれLoginUserConfigクラスのusername属性とpassword属性にバインドされます。ConfigControllerに挿入した後、対応するプロパティ値を取得できます。また、リクエストを実行すると、getConfigParamsメソッドに出力される対応するログは次のようになります。
- ConfigurationProperties configユーザー名：test-admin
- ConfigurationProperties configパスワード：test- pwd
上記の例は、@ ConfigurationPropertiesバインディングプロパティの場合のみを示しています。SpringBootがEnvironmentプロパティを@ConfigurationPropertiesで注釈が付けられたBeanにバインドする場合、いくつかの緩いルールも使用できます。つまり、Environmentプロパティ名とBeanプロパティ名は正確である必要はありません。一致。
たとえば、UserオブジェクトにfirstName属性がある場合、構成ファイル内の次の構成項目が一致します。
- user。firstName//標準のラクダケースの命名構文
- user。first-name//ダッシュで区切って.propertiesおよび.ymlファイルでの使用を推奨
- user。first_name//下線付き、.propertiesおよびymlファイルのオプション形式です
- USER_ FIRST _NAME //大文字、システム環境変数に推奨
同時に、タイプの安全性に基づく属性構成を@Validatedアノテーションと組み合わせて、空でないかどうか、正しい携帯電話番号（email）形式かどうか、正しい日付かどうかなどの属性制約の検証を行うこともできます。これらはここでは展開されません。アップ。
この例で拡張を試みることができます。
最後に、このセクション全体の例の主要な内容を確認しましょう。最初に、プロファイルメカニズムに基づいて、複数の環境の構成ファイルを設定します。次に、spring。profiles。activeconfigurationを介して、使用する環境の特定のパラメーター値を指定し、次に渡します。 @Valueおよび@ConfigurationPropertiesアノテーションは、これらの構成プロパティをクラスプロパティまたはBeanオブジェクトにバインドします。最終的にそれらを取得し、特定のシナリオで使用します（この例は印刷用です）。
具体的には、優先度の問題も発生します。たとえば、特定のパラメータをコマンドラインパラメータで直接指定すると、構成ファイル内のパラメータが同じ名前で上書きされます。別の例として、アプリケーション構成ファイルがプロジェクトの同じディレクトリに配置されている場合、その優先度はjarパッケージの構成よりも高くなります。これらの内容は原則の章でカバーされています。読者はこの例を参照して、1つずつ確認および調査できます。
概要
この章では、Spring Bootでのパラメータ転送プロセスと構成ファイルのロード、特にプロファイルベースのロードメカニズムに焦点を当てます。ロード、デフォルト構成、構成の優先順位、およびその他の操作はすべてConfigFileApplicationListenerクラスにあります。このクラスは、読者が学習する価値があります。
実際の戦闘部分では、簡単な例を通じていくつかの原則の使用法を示しています。この例を組み合わせて、より関連する機能を検証および使用できます。
最後に、この章にはより多くのソースコードとより深いロジックレベルが含まれるため、異なる構成モードは異なる組み合わせを形成し、より多くのシナリオを形成します。したがって、学習プロセス中のデバッグを通じて操作の各ステップを追跡することをお勧めします。プロセス全体を理解します。