Une application Web Spring standard (créée par Roo ou modèle "Spring MVC Project") crée un fichier web.xml avec ContextLoaderListener
et DispatcherServlet
. Pourquoi n'utilisent-ils pas seulement le DispatcherServlet
et le font-ils pour charger la configuration complète?
Je comprends que le ContextLoaderListener doit être utilisé pour charger les éléments qui ne sont pas pertinents pour le Web et que le DispatcherServlet est utilisé pour charger les éléments pertinents pour le Web (contrôleurs, ...). Et ce résultat dans deux contextes: un contexte parent et un contexte enfant.
Contexte:
Je le faisais de cette manière standard pendant plusieurs années.
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:META-INF/spring/applicationContext*.xml</param-value>
</context-param>
<!-- Creates the Spring Container shared by all Servlets and Filters -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!-- Handles Spring requests -->
<servlet>
<servlet-name>roo</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>WEB-INF/spring/webmvc-config.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Cela posait souvent des problèmes avec les deux contextes et les dépendances entre eux. Dans le passé, j'ai toujours pu trouver une solution et j'ai le fort sentiment que cela améliore toujours la structure / l'architecture du logiciel. Mais maintenant je suis confronté à un problème avec les événements des deux contextes .
- Cependant, cela me fait repenser ce modèle à deux contextes, et je me demande: pourquoi devrais-je me retrouver dans ce problème, pourquoi ne pas charger tous les fichiers de configuration de printemps avec un DispatcherServlet
et supprimer ContextLoaderListener
complètement le. (Je veux toujours avoir différents fichiers de configuration, mais un seul contexte.)
Y a-t-il une raison de ne pas supprimer le ContextLoaderListener
?
Réponses:
Dans votre cas, non, il n'y a aucune raison de conserver le
ContextLoaderListener
etapplicationContext.xml
. Si votre application fonctionne correctement avec uniquement le contexte du servlet, cela reste plus simple.Oui, le modèle généralement recommandé est de conserver les éléments non Web dans le contexte au niveau de l'application Web, mais ce n'est rien de plus qu'une convention faible.
Les seules raisons convaincantes d'utiliser le contexte au niveau de l'application Web sont:
DispatcherServlet
qui doivent partager des servicesDelegatingFilterProxy
,OpenEntityManagerInViewFilter
etc.)Aucun de ces éléments ne s'applique à vous, donc la complexité supplémentaire est injustifiée.
Soyez juste prudent lorsque vous ajoutez des tâches d'arrière-plan au contexte du servlet, comme des tâches planifiées, des connexions JMS, etc. Si vous oubliez d'ajouter
<load-on-startup>
à votreweb.xml
, ces tâches ne seront pas lancées avant le premier accès au servlet.la source
DispatcherServlet
sans configuration - si vous faisiez cela, vous n'auriez pas d'interface Web. Tous les trucs MVC doivent y aller.Vous pouvez également configurer le contexte de l'application dans l'autre sens. Par exemple, pour faire fonctionner OpenEntityManagerInViewFilter . Configurez le ContextLoaderListener , puis configurez votre DispatcherServlet avec:
Assurez-vous simplement que la valeur du paramètre contextConfigLocation est vide.
la source
Je souhaite partager ce que j'ai fait sur mon application Spring-MVC:
Sur le
we-mvc-config.xml
j'ai ajouté juste les classes annotées avec @Controller:Sur les
applicationContext.xml
fichiers j'ai ajouté tout le reste:la source