構成カバレッジはプロファイルよりも優れています
生産慣行では、構成カバレッジは、さまざまな環境で異なる構成を解決する一般的な方法です。たとえば、生産サーバー上の構成ファイルを使用してパッケージ内のファイルを上書きするか、集中型構成サービスを使用してデフォルトのビジネス構成を上書きします。
プロファイルメカニズム（MavenのプロファイルやSpring Bootのプロファイル固有のプロパティなど）と比較して、さまざまな環境が異なる構成ファイルを使用し、オーバーレイ方法がより有利です。プログラマーは、開発中に生産環境データベースの住所、アカウント、その他の情報を気にする必要はありません。一度に構築することで、さまざまな環境で実行できます。プロファイルメカニズムは、生産環境の構成をプロジェクトリソースファイルに書き込む必要があり、さまざまな環境に異なる構造パラメーターまたは操作パラメーターを使用する必要があります。
Springは、カスタム属性ソースをITに統合するための複数の方法を備えた柔軟な構成拡張機能を提供し、簡単な構成カバレッジを可能にします。
この記事は、スプリングブート1.4.8/スプリング4.3.12に基づいて書かれています
@PropertySourceアノテーションを使用して、カスタム構成ファイルと構成オーバーライドを実装する
@configurationproperties@configurationpublic class demoproperties {// getter/settersを備えたプロパティ} @propertySource（value = {"test.properties"、 "file：/etc/test.properties"、}、ingoreresourcenotfound = true）@configurationpublic class demoautoconfiguration {@autowired private demoperties demoperties; @postconstruct public void init（）{system.out.println（demoproperties）; }}Springは、「test.properties」がclassPathからファイルをロードする「test.properties」を使用して、プロパティソースアノテーションを使用してカスタム構成ファイルの導入をサポートします。ファイル：/etc/test.properties "により、Springはファイルシステムから/etc/test.propertiesファイルをロードします。
同時に、「file：/etc/test.properties」は「test.properties」の後に配置されるため、ファイルシステム構成ファイルがClassPathの構成を上書きすることができます。
カスタムプロパティソースファクトリー
集中構成サービスのロード構成など、プロパティソースをより柔軟にカスタマイズする場合は、PropertySourceFactoryインターフェイスを実装し、PropertySourceアノテーションの工場パラメーターを構成できます。
@configuration@propertySource（value = ""/*placeholder*/、factory = compositePropertySourceFactory.class）public class compositeconfigautoconfiguration {}値フィールドは、構成ソースに対応するリソースファイルを指定するために使用されます。リソースファイルが不要な場合は、任意の値として構成できます。パラメーター値は、工場パラメーターのcreatepropertySourceメソッドに渡されます。
IgnoreresourcenotFoundフィールドがTrueとして指定されている場合、工場でスローされる例外は無視されます。そうしないと、スタートアップが失敗します。時には、スタートアップの失敗を直接暴露することをお勧めします。
PropertySourceFactoryインターフェイスの定義は次のとおりです。
/***リソースベースの{@link PropertySource}ラッパーを作成するための戦略インターフェイス。 * * @author juergen hoeller * @since 4.3 * @see defaultpropertysourcefactory * /public interface propertySourceFactory { /** *指定されたリソースをラップする{@link propertySource}を作成します。 * @param名プロパティソースの名前 * @paramリソースリソース（潜在的にエンコードされた）@return new {@link propertySource}（never {@code null}） * @throws IOExceptionが失敗した場合 */ propertySource <？PropertySourceFactoryのローディング時間は、Spring Beans容器よりも早いため、実装はSpringのIOCに依存できないことに注意する必要があります。
PropertySourceFactoryは、PropertySourceを返すために実装クラスが必要です。 PropertySourceは、Springプロパティ（または構成）関数のコアインターフェイスであり、次のような多くの実装があります。
実際の実装クラスはこれらよりはるかに劣っています。特定の目的のために、Springドキュメントまたはソースコードを読むことができます。
MappropertySourceとComposityPropertySourceは、プロパティソースをカスタマイズするときに一般的に使用されます。
MappRopertySourceを使用して、それ自体がロードされるプロパティデータをラップし、その構築方法を参照してください。
public mappropertysource（string name、map <string、object> source）{super（name、source）;}後者は、オーバーライド順序を組み合わせてカスタマイズすることにより、複数の属性ソースをロードできます。例えば：
PropertySource <？ compositepropertysource.addpropertysource（packageinsidepropertysource）; propertySource <？> outerfilepropertysource = outerfilepropertysourceiterateLoader.loadpropertysource（compositepropertysource）; compositepropertysource.addfirstpropertysource（outourfilepropertysource）;
AddFirstPropertySourceメソッドは、着信プロパティソースを最優先事項に設定できます（このCompositePropertySource内）、AddPropertySourceメソッドは逆であり、その後は優先度が低くなります。
依存関係JARパッケージに同じ名前のすべての構成ファイルをロードする
ClassPathから構成ファイルを直接読み込むには、ファイルがclassPathに存在する必要があります。 Webプロジェクトでは、ファイルが依存関係のJARパッケージに存在する場合、つまりWeb-INF/LIB/XXX.JARにある場合、ClassPathに基づいて直接ロードすることはできません。この時点で、Springが提供するPathMatchingResourcePatterNresolverを使用して、すべてのJARパッケージをリソース名でスキャンして目的を達成できます。
プライベートリスト<sorstice> getPackageInsiderSourcesBypattern（String ResourceName）throws ioException {string resourcepatternresolver.classpath_all_url_prefix + hbootconfigconstants.configs + resourcename; ResourcePatterNresolver ResourcePatterNresolver = new PathMatchingResourcePatterNresolver（）; return arrays.aslist（resourcepatternresolver.getResources（ResourcePathPattern））;}次に、ResourcePropertySourceを使用して、ResourceからPassまでPropertySourceを構築できます。
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。