Où mettre le fichier de configuration Spring?

Je souhaite intégrer le framework Spring dans mon projet en particulier côté serveur.

Donc, je ne veux pas le mettre dans le dossier WEB-INF du fichier de guerre.

Dois-je mettre un applicationContext.xml dans chaque couche (signifie chaque projet depuis divisé en projets distincts? (Services, Domaine et DAO)

Quelle est la bonne pratique?

La structure du fichier Maven peut aider à cela

En substance, les fichiers de configuration de Spring (qui peuvent avoir n'importe quel nom en passant, pas seulement le générique applicationContext.xml) sont traités comme des ressources de chemin de classe et classés sous src/main/resources. Pendant le processus de construction, ceux-ci sont ensuite copiés dans le WEB-INF/classesrépertoire qui est l'endroit normal où ces fichiers se retrouvent.

Les variantes incluent un springrépertoire supplémentaire (par exemple src/main/resources/spring) pour séparer les contextes Spring des autres ressources dédiées aux frameworks d'application. Vous souhaiterez peut-être diviser les contextes d'application en couches dédiées telles que:

example-servlet.xml
example-data.xml
example-security.xml

etc.

Qu'en est-il des différents environnements comme dev / test / production?

En règle générale, votre configuration Spring doit récupérer la configuration de l'environnement à partir de son, ahem, environnement. Cela signifie généralement utiliser JNDI, JDBC, des variables d'environnement ou des fichiers de propriétés externes pour fournir la configuration nécessaire. Je les répertorie par ordre de préférence, car JNDI est généralement plus facile à administrer que les fichiers de propriétés externes dans un cluster de production contrôlé.

Dans le cas des tests d'intégration, vous devrez peut-être utiliser un fichier de configuration Spring "test uniquement". Cela contiendrait des contextes spéciaux qui utilisent des beans de test ou une configuration. Ceux-ci seraient présents sous src / test / resources et pourraient avoir un test-préfixe pour s'assurer que les développeurs sont conscients de leur objectif. Une utilisation typique serait de fournir une source de données non JNDI ciblant peut-être une base de données HSQLDB pendant les tests automatisés de génération et serait référencée dans le scénario de test.

Cependant, en général, la majorité de vos fichiers de contexte Spring ne doivent pas nécessiter de modification spécialisée lorsqu'ils se déplacent entre les niveaux. Il devrait être le cas que le même artefact de construction (par exemple, un fichier WAR) est utilisé dans dev / test / production avec des informations d'identification différentes.

Votre projet est-il divisé en modules Maven? Si c'est le cas, vous pouvez ajouter un module supplémentaire uniquement pour les fichiers de configuration. Appelons-le config-module

config-module
      |
      |--> src\main\resources\config\spring\applicationContex.xml
      |--> src\main\resources\config\properties\application.properties
      |--> pom.xml

Une telle configuration est une suggestion. Configurez votre propre ensemble de fichiers Emballez-le comme un JAR et ajoutez ce module en tant que dépendance de tout autre module (web, ear's lib, autre jar).

Vous aurez accès aux ressources du module de configuration (xml, propriétés, etc.) car elles se trouvent dans le chemin d' accès aux classes.

pom du module web

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

Utilisez ensuite des instructions d' importation à partir de fichiers de contexte Spring externes. Par exemple

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