私のプロジェクトのSpringフレームワークを、特にサーバー側に統合したいと考えています。
ですから、warファイルのWEB-INFフォルダーに入れたくありません。
ApplicationContext.xmlを各レイヤーに配置する必要があります(個別のプロジェクトに分割されているため、各プロジェクトを意味しますか?(サービス、ドメイン、およびDAO)
良い習慣は何ですか?
Mavenファイル構造 はこれに役立ちます
基本的に、Spring構成ファイル(一般的なapplicationContext.xml
だけでなく、任意の名前を付けることができます)は、クラスパスリソースとして扱われ、src/main/resources
の下にファイルされます。ビルドプロセス中に、これらはこれらのファイルが最終的に置かれる通常の場所であるWEB-INF/classes
ディレクトリにコピーされます。
バリエーションには、Springコンテキストをアプリケーションフレームワーク専用の他のリソースから分離するための追加のspring
ディレクトリ(src/main/resources/spring
など)が含まれています。アプリケーションコンテキストを次のような専用のレイヤーに分割したい場合があります。
example-servlet.xml
example-data.xml
example-security.xml
等々。
dev/test/productionのような異なる環境についてはどうですか?
通常、Spring構成は、その環境から環境構成を取得する必要があります。通常、これは、JNDI、JDBC、環境変数、または外部プロパティファイルを使用して必要な構成を提供することを意味します。 JNDIは一般に、制御された実稼働クラスターの外部プロパティー・ファイルよりも管理が容易であるため、それらを優先順にリストします。
統合テストの場合は、「テスト専用」のSpring構成ファイルを使用する必要があります。これには、テストBeanまたは構成を使用する特別なコンテキストが含まれます。これらはsrc/test/resourcesの下にあり、test-
接頭辞を付けて、開発者がその目的を認識していることを確認できます。典型的な使用法は、JNDI以外のDataSourceを提供することです。おそらく、自動テストのビルド中にHSQLDBデータベースをターゲットとし、テストケース内で参照されます。
ただし、一般に、Springコンテキストファイルの大部分は、階層間を移動するため、特別な変更は必要ありません。同じビルドアーティファクト(WARファイルなど)が、異なる資格情報でdev/test/productionで使用されている場合も同様です。
プロジェクトはMavenモジュールに分割されていますか?その場合は、構成ファイル専用のモジュールを追加できます。それを呼び出しましょうconfig-module
config-module
|
|--> src\main\resources\config\spring\applicationContex.xml
|--> src\main\resources\config\properties\application.properties
|--> pom.xml
このような構成は提案です。独自のファイルセットをセットアップします[〜#〜] jar [〜#〜]のようにパッケージ化して追加しますこのモジュールは、他のモジュール(web、ear's lib、別のjar)の依存関係として存在します。
クラスパスにあるため、config-moduleリソース(xml、プロパティなど)にアクセスできます。
web-module's pom
<dependency>
<groupId>com.myproject.group</groupId>
<artifactId>config-module</artifactId>
</dependency>
次に、外部Springコンテキストファイルからimportステートメントを使用します。例えば
<import resource="classpath*:com/package/subpackage/**/config/applicationContext.xml" />