ContextLoaderListener ou pas?
Un standard de printemps de l'application web (créé par Roo ou "Spring MVC Projet" Template) créer un web.xml avec ContextLoaderListener
et DispatcherServlet
. Pourquoi ne sont-ils pas seulement utiliser le DispatcherServlet
et le rendre à la charge de l'ensemble de la configuration?
Je comprends que le ContextLoaderListener doit être utilisé pour charger le matos qui n'est pas web pertinents et la DispatcherServlet est utilisé pour charger le web pertinentes de la substance (Contrôleurs,...). Et ce résultat dans deux contextes: un parent et un enfant de cadre.
De fond:
J'ai été le faisant de cette manière standard pour 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 a souvent causé des problèmes avec les deux contextes et les dépendances entre eux. Dans le passé j'ai toujours été en mesure de trouver une solution, et j'ai le sentiment très fort que cela fait de la structure du logiciel/architecture de toujours mieux. Mais maintenant, je suis confronté à un problème avec les événements de ces deux contextes.
-- Toutefois, cela me fait repenser à ce double contexte motif, et que je me pose: pourquoi devrais-je me résoudre à ce problème, pourquoi ne pas le chargement de tous les printemps les fichiers de configuration avec un DispatcherServlet
et la suppression de la ContextLoaderListener
complètement. (J'ai encore d'avoir des fichiers de configuration différents, mais un seul contexte.)
Est-il une raison de ne pas retirer la ContextLoaderListener
?
- "Cela a souvent causé des problèmes avec les deux contextes et les dépendances entre eux." C'est un excellent exemple de la façon dont je pense que l'injection de dépendance cadres rendre notre vie plus difficile que de le faire vous-même l'injection de dépendance.
- Alors que j'ai une certaine sympathie avec ce point de vue, je ne peux m'empêcher d'avis que les cas d'utilisation pour laquelle vous avez besoin de deux contextes (partage d'objets entre les filtres de sécurité et de servlets, de gérer automatiquement les transactions, de sorte qu'ils sont fermés après le point de vue que vous rediriger vers a rendu terminé) sont assez difficile à réaliser sans l'aide du cadre. C'est surtout parce que la servlet API a été clairement jamais conçu pour fonctionner avec l'injection de dépendance à tous, et travaille activement contre vous, si vous essayez de le faire vous-même.
- Je vois! Eh bien, pensez-vous que si il avait été conçu différemment qu'il y aurait de meilleures alternatives à Spring MVC? Bien que les gens pourraient avoir conçu complète de solutions de rechange à la Servlet API de toute façon...
- Il est intéressant de noter que dans le JS monde, où j'ai été en utilisant Express pour le routage des requêtes HTTP pour environ un an, j'ai rarement l'occasion de voir toute mention de "l'injection de dépendance" et rien qui ressemble à du framework Spring à tous.
Vous devez vous connecter pour publier un commentaire.
Dans votre cas, non, il n'y a aucune raison de garder la
ContextLoaderListener
etapplicationContext.xml
. Si votre application fonctionne très bien avec juste la servlet contexte, que s'en tenir à cela, c'est plus simple.Oui, généralement, encouragée modèle est de garder les contenus du web dans la webapp niveau du contexte, mais ce n'est rien de plus qu'une faiblesse de la convention.
Les seules des raisons convaincantes de l'utilisation de la webapp niveau de contexte sont les suivantes:
DispatcherServlet
qui ont besoin de partager des servicesDelegatingFilterProxy
,OpenEntityManagerInViewFilter
, etc)Aucune de ces situations s'applique à vous, de sorte que le supplément de complexité est injustifiée.
Juste être prudent lors de l'ajout de tâches en arrière-plan de la servlet contexte, telles que la planification des tâches, JMS connexions, etc. Si vous oubliez d'ajouter
<load-on-startup>
à votreweb.xml
, ces tâches ne seront pas commencé jusqu'à ce que le premier accès de la servlet.DispatcherServlet
sans configuration - si vous l'avez fait, vous auriez pas d'interface web. Tous MVC trucs a y aller.Vous pouvez configurer le contexte de l'application dans l'autre sens aussi bien. E. g. afin de rendre le OpenEntityManagerInViewFilter travail. Installation de la ContextLoaderListener et ensuite configurer votre DispatcherServlet avec:
Assurez-vous que le contextConfigLocation valeur de paramètre est vide.
org.springframework.web.servlet.handler.SimpleUrlHandlerMapping
et ensuite fourni les mappages. Je ne suis pas un Printemps Maître, mais je dirais que la raison pour laquelle c'est le cas c'est parce que le DispathlerServlet ne prend pas seulement le contexte et crée des haricots, il assurez-vous également MVC fonctionnalités connexes (comme la cartographie) est faitJe veux partager ce que j'ai fait sur mon Spring-MVC de l'application:
Sur le
we-mvc-config.xml
j'ai ajouté les classes annotées avec @Controller:Sur le
applicationContext.xml
fichiers, j'ai ajouté tout le reste: