ContextLoaderListener ou non?

Une application Web à ressort standard (créée par Roo ou modèle “Spring MVC Project”) crée un ContextLoaderListener web.xml avec ContextLoaderListener et DispatcherServlet . Pourquoi utilisent-ils non seulement le DispatcherServlet et le font pour charger la configuration complète?

Je comprends que 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 du Web (contrôleurs, …). Et cela se traduit par deux contextes: un parent et un contexte enfant.

Contexte:

Je le faisais de cette manière depuis plusieurs années.

  contextConfigLocation classpath*:META-INF/spring/applicationContext*.xml    org.springframework.web.context.ContextLoaderListener    roo org.springframework.web.servlet.DispatcherServlet  contextConfigLocation WEB-INF/spring/webmvc-config.xml  1  

Cela causait souvent des problèmes avec les deux contextes et les dépendances entre eux. Dans le passé, j’ai toujours été capable de trouver une solution et j’ai le sentiment que cela rend la structure / architecture du logiciel toujours meilleure. Mais maintenant, je suis confronté à un problème avec les événements des deux contextes .

– Cependant, cela me permet de repenser ce modèle de contexte, et je me demande: pourquoi devrais-je résoudre ce problème, pourquoi ne pas charger tous les fichiers de configuration Spring avec un DispatcherServlet et supprimer complètement ContextLoaderListener . (Je vais toujours avoir des fichiers de configuration différents, mais un seul contexte.)

Y a-t-il une raison de ne pas supprimer ContextLoaderListener ?

Dans votre cas, non, il n’y a aucune raison de conserver ContextLoaderListener et applicationContext.xml . Si votre application fonctionne correctement avec le contexte de la servlet, cela est plus simple.

Oui, le modèle généralement encouragé consiste à conserver des éléments non Web dans le contexte de l’application Web, mais ce n’est rien de plus qu’une convention faible.

Les seules raisons impérieuses d’utiliser le contexte au niveau de l’application Web sont les suivantes:

  • Si vous avez plusieurs DispatcherServlet qui doivent partager des services
  • Si vous avez des servlets hérités / non-Spring nécessitant un access aux services filaires Spring
  • Si vous avez des filtres de servlet qui accèdent au contexte de niveau WebApp (par exemple, DelegatingFilterProxy , OpenEntityManagerInViewFilter , etc. de Spring Security)

Aucun de ces éléments ne vous concerne, la complexité supplémentaire est donc injustifiée.

Soyez prudent lorsque vous ajoutez des tâches en arrière-plan au contexte de la servlet, comme des tâches planifiées, des connexions JMS, etc. Si vous oubliez d’append à votre web.xml , ces tâches ne seront pas lancées access de la servlet.

Vous pouvez également configurer le contexte de l’application dans l’autre sens. Par exemple, pour faire fonctionner OpenEntityManagerInViewFilter . Configurez ContextLoaderListener , puis configurez votre DispatcherServlet avec:

  spring-mvc org.springframework.web.servlet.DispatcherServlet  contextConfigLocation    

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

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

  1. Sur le we-mvc-config.xml j’ai ajouté seulement les classes annotées avec @Controller:

        
  2. Sur les fichiers applicationContext.xml , j’ai ajouté tout le rest: