web-dev-qa-db-fra.com

Où placer 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?

javasoaspring
18
Mik378

La structure du fichier Maven peut aider à cela

En substance, les fichiers de configuration de Spring (qui peuvent avoir n'importe quel nom d'ailleurs, 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. Au cours du processus de génération, ceux-ci sont ensuite copiés dans le WEB-INF/classes répertoire qui est l'endroit normal où ces fichiers se retrouvent.

Les variantes incluent un répertoire spring 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. Habituellement, cela signifie 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ée.

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 peuvent 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, le fichier WAR) est utilisé dans dev/test/production uniquement avec des informations d'identification différentes.

25
Gary Rowe

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. Permet de l'appeler module-config

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 pot [~ # ~] [~ # ~] et ajoutez ce module comme dépendance de tout autre module (web, ear's lib, autre jar).

Vous aurez accès aux ressources config-module (xml, propriétés, etc.) car elles se trouvent dans le chemin de classe.

pom du module web

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

Utilisez ensuite les instructions import à partir des fichiers de contexte Spring externes. Par exemple

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