Où vont les fichiers de configuration du bean Spring dans un module WAR Maven?

Question

J'ai regardé un tas de projets d'exemples et je n'arrive pas à dégager une bonne pratique commune. J'ai vu des fichiers de configuration de bean Spring aller parfois dans le répertoire src/main/webapp/WEB-INF. Je l'ai vu en conjonction avec une définition Servlet dans web.xml comme ceci:

<servlet> 
    <servlet-name>my-stuff</servlet-name> 
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 
    <init-param> 
     <param-name>contextConfigLocation</param-name> 
     <param-value>/WEB-INF/my-stuff-servlet.xml</param-value> 
    </init-param> 
    <load-on-startup>1</load-on-startup> 
</servlet> 

Mais j'ai aussi vu des fichiers de configuration de haricots inclus dans web.xml haut niveau - à savoir en dehors d'un Servlet. Qu'est-ce que ça veut dire? Est-ce pour les haricots croisés-Servlet? Parfois, c'est dans le répertoire src/main/webapp/WEB-INF et parfois c'est dans src/main/resources. J'ai également vu d'autres fichiers de configuration de bean définis dans les modules WAR avec à peu près tout dans src/main/resources. J'ai lu et relu la documentation de Spring, mais la seule convention que j'ai trouvée est que par défaut un fichier de configuration de contexte Servlet doit être dans le répertoire src/main/webapp/WEB-INF nommé {servlet-name}-servlet.xml.

Alors, quelle est la meilleure pratique et pourquoi?

Answer 1

Les contextes d'application dans Spring peuvent former des hiérarchies où le contexte enfant a accès aux beans définis dans le contexte parent.

Une application web typique Spring MVC contient une hiérarchie à deux niveaux:

• Racine contexte d'application web chargée par ContextLoaderListener. L'emplacement de configuration de ce contexte est applicationContext.xml par défaut et peut être configuré en utilisant <context-param> nommé contextConfigLocation, c'est-à-dire au niveau supérieur de web.xml. Ce contexte contient généralement une logique d'application principale.

• Contexte spécifique au servlet chargé par DispatcherServlet. Son emplacement de configuration est par défaut <servletname>-servlet.xml et peut être configuré en utilisant <init-param> nommé contextConfigLocation, c'est-à-dire au niveau de la servlet. Ce contexte contient généralement un élément lié à Spring MVC (contrôleurs, etc.) car DispatcherServlet fait partie de Spring MVC.

Ce dernier contexte est un enfant du premier.

Si l'application Web n'utilise pas Spring MVC comme cadre de présentation, elle n'a pas DispatcherServlet et son contexte. Certains exemples Spring MVC extrêmement simples n'ont pas le ContextLoaderListener et le contexte racine (cependant, vous avez besoin d'un contexte racine pour les fonctionnalités de servlet croisé telles que Spring Security).

Les fichiers de configuration de l'application Web sont par défaut situés dans le dossier racine de webapp. Cependant, ils peuvent être placés dans le chemin de classe (c'est-à-dire dans src/main/webapp), dans ce cas, ils sont accédés via le préfixe classpath:. Cela peut être utile si vous utilisez certains de ces fichiers dans des tests d'intégration sans conteneur de servlet. Le préfixe classpath: peut également être utile lorsque vous souhaitez charger un fichier de configuration à partir d'un artefact distinct, c'est-à-dire à partir d'un fichier jar dans /WEB-INF/lib.

Answer 2

Je pense que c'est souvent un bon style de garder le code, sa configuration de ressort dans un JAR séparé qui est inclus dans le WAR, de sorte que le WAR est fondamentalement vide mais pour web.xml et autres. Cela vous évite même de poser cette question. :-) Vous pouvez référencer ces configurations de ressort avec classpath: prefix.Un des avantages de cette mise en page est que vous pouvez facilement écrire Unittests qui instancie la configuration Spring complète du WAR dans le JAR. Je ne recommanderais pas nécessairement de l'utiliser pour des tests réels (bien que vous puissiez faire des tests d'intégration de cette façon), mais vous obtenez une réaction rapide lorsque vous cassez la structure globale des fichiers de configuration sans avoir à redéployer l'application. Si vous avez vraiment besoin de mettre des fichiers de configuration de printemps dans le WAR (peut-être aussi parce qu'il fait référence aux beans implémentés dans le WAR), je les mettrais aussi dans le chemin des ressources normales/WEB-INF/classes, pour le raisons discutées ci-dessus.