Spring構成ファイルを配置する場所

プロジェクトの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-し、開発者が目的を確実に認識できるように接頭辞を付けることができます。典型的な使用法は、自動テストのビルド中にHSQLDBデータベースをターゲットとする非JNDI DataSourceを提供し、テストケース内で参照することです。

ただし、一般的に、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モジュールのPOM

<dependency>
    <groupId>com.myproject.group</groupId>
    <artifactId>config-module</artifactId>
</dependency>

次に、外部のSpringコンテキストファイルからimportステートメントを使用します。例えば

<import resource="classpath*:com/package/subpackage/**/config/applicationContext.xml" />