プロファイルは確かにその問題の解決策ですが、このアプローチは、ターゲット プラットフォームでのみ発見される問題への別の大きな扉を開くと思います。
私のプロジェクトでは、常にプロパティを外部化し、できるだけ多くのプロパティをランタイム パラメータに変換してきました。
Jenkins/Sonar/etc を再度バンドルする必要があると想像してみてください。これは、プラットフォームがクラスパスに存在するプロパティを持つプロファイルの一部にならないためです。私は、これらが成功したプロジェクトになるとは思わない ;)
春に関しては、クラスパスからの「デフォルト」プロパティを置き換えることができるように、プロパティ設定者で「file://」プロトコルを使用できます。したがって、順序パラメーターとその他のプロパティを持つ 2 つの構成タグがあります。次に例を示します。
<jee:jndi-lookup id="configDirectory" jndi-name="configDirectory"
resource-ref="true" default-value="." />
<jee:jndi-lookup id="datasource" jndi-name="jdbc/datasource"
expected-type="javax.sql.DataSource" default-ref="localDatasource" />
<!-- Allows fetching properties from multiple locations: -->
<!-- external definition -> file://${configDirectory}/root-context.properties
-> declared in context.xml -->
<!-- standard web application bundle -> /WEB-INF/spring/root-context.properties -->
<!-- testing -> classpath:root-context.properties -->
<context:property-placeholder location="${configDirectory:.}/context.properties"
order="9" ignore-resource-not-found="true" ignore-unresolvable="true" />
<context:property-placeholder
location="/WEB-INF/spring/context.properties,
classpath:context.properties"
order="10" ignore-resource-not-found="true" ignore-unresolvable="true" />
<context:property-placeholder location="classpath:spring/default.properties"
order="100" />
このように、ローカルでビルドし、maven ビルド中に単体テストと統合テストを実行し、UAT でビルドを実行し、問題がなければ、war ファイルを変更することなく UAT から PROD にビルドをコピーできます。
プロパティでは、実行時に変更できないすべてのパラメーターを定義します。これは、基本的に Hibernate パラメーターとその他のパラメーターです。
残りはすべて、単純なシステム パラメータ (キーと値のペア) としてデータベースに格納されます。修正する必要のないプロパティがたくさんあります。これには、LDAP、MailSender、tempdir などのフォルダー定義が含まれます。
データソースは最初に開始される Bean の 1 つであるため、現在実行中のプロジェクトではこれが非常にうまく機能し、データベースにプッシュされるプロパティがさらに発見されています。