122 votes

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 n'ont-ils pas seulement utiliser l' 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.

Arrière-plan:

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.

-- Cependant, 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 enlever l' ContextLoaderListener?

86voto

skaffman Points 197885

Dans votre cas, non, il n'y a pas de raison de conserver l' ContextLoaderListener et applicationContext.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:

  • Si vous avez plusieurs DispatcherServlet qui ont besoin de partager des services
  • Si vous avez des legs/non-Printemps des servlets qui ont besoin d'accéder à de Printemps-les services filaires
  • Si vous avez servlet filtres crochet dans le webbapp niveau de contexte (par exemple, le Printemps de Sécurité de l' DelegatingFilterProxy, 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> votre web.xml, ces tâches ne seront pas commencé jusqu'à ce que le premier accès de la servlet.

10voto

Modi Points 246

Je veux partager ce que j’ai fait sur mon application Spring-MVC :

  1. Sur le `` j’ai ajouté juste les classes annotées par @Controller :
  2. Sur le `` tout le reste, j’ai ajouté les fichiers :

10voto

Gunnar Hillert Points 133

Vous pouvez configurer le contexte de l’application l’inverse aussi bien. Par exemple pour faire fonctionner le OpenEntityManagerInViewFilter . Le ContextLoaderListener de configuration, puis de configurer votre DispatcherServlet avec :

Assurez-vous simplement que la valeur du paramètre contextConfigLocation est vide.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X