マルチモジュールプロジェクトでスプリングブートを使用しています。
共通のドメインオブジェクトクラス、リポジトリ、およびデータソース、JPA、Hibernateなどの構成を持つドメインアクセスモジュールがあります。これらはapplication.propertiesを使用して構成されます。これらすべての構成を共通モジュールに配置して、これらの共通構成を上位レベルのモジュールで複製する手間を省きます。
これはドメインモジュールの構築時にすべて正常に機能するため、構成はテストユニットに正しく読み込まれます。
しかし、上位層モジュールでドメインモジュールを使用しようとすると、問題が発生します。それらは独自のapplication.propertiesを持っています。これは、Springがドメインモジュールapplication.propertiesではなくそれらをロードすることを意味します。つまり、より高いモジュールapplication.propertiesのみがロードされるため、データソースは構成されません。
私たちが望むのは、Springによってロードされるドメインモジュールと上位レベルのアプリケーションプロパティの両方です。しかし、これを行う簡単な方法はありません。
これは一般的な問題だと思いますが、この問題の推奨される解決策はありますか?
Spring-Bootを使用しているため、ソリューションではapplictionContext.xmlではなくアノテーションを使用するのが理想的です。
たぶん、トップレベルのアグリゲータープロジェクトでのみapplication.properties
を使用する必要がありますか?
子プロジェクトでいつでも@PropertySource
を使用して、ユースケースに固有の名前でそれらを構成できます。
または、プロジェクトごとに異なる名前を使用し、spring.config.location
(カンマ区切り)を使用して最上位プロジェクトでそれらを結合することができます。
@Dave Syerに同意します。アプリケーションを複数のモジュールに分割するアイデアは、それらのそれぞれが独立したユニット、この場合はjarファイルであるということです。理論的には、これらのjarファイルをそれぞれ独自のソースリポジトリに分割し、それらを複数のプロジェクトで使用できます。これらのドメインクラスをWebアプリケーションとバッチアプリケーションの両方で再利用するとします。すべてのAPPLICATIONレベルの構成が個々のモジュールのそれぞれに格納されている場合、再利用性が大幅に低下します。
IMOには集約モジュールのみが、アプリケーションとして実行するために必要なすべての構成を含める必要があります。その他はすべて、必要に応じて再混合および再利用できる依存関係にすぎません。
多分別のアプローチは、各モジュールに特定のプロファイルを定義し、 spring.profiles.include プロパティを使用してウィッチプロファイルがアクティブであることを指定するためだけにapplication.propertiesファイルを使用することです。
domain-module
- application.properties
- application-domain.properties
app-module
- application.properties
- application-app.properties
そしてapp-moduleのapplication.propertiesファイルに
spring.profiles.include=domain,app
あなたができるもう1つのこと(Dave Syerが言及するようにトップレベルでapplication.propertiesを使用すること以外に)は、ドメインモジュールのプロパティファイルにdomainConfig.properties
のような名前を付けることです。
そうすることで、名前がapplication.properties
と競合するのを回避できます。
domainConfig.properties
には、ドメインモジュールが独自にテストできるようにするために必要なすべてのデータが含まれます。残りのコードとの統合は、複数の@PropertySource
(domainConfig.properties
用とapplication.properties
用)を使用するか、PropertySourcesPlaceholderConfigurer
Beanを= Java構成(チェックアウト this チュートリアル))必要なすべてのプロパティファイルを参照