Rôle/Objet de ContextLoaderListener au Printemps?

ContextLoaderListener est facultatif . Juste pour faire un point ici: vous pouvez démarrer une application de ressort sans jamais configurer ContextLoaderListener , juste un minimum de base web.xml avec DispatcherServlet .

voici à quoi il ressemblerait:

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns="http://java.sun.com/xml/ns/javaee" 
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
    xsi:schemaLocation="
        http://java.sun.com/xml/ns/javaee 
        http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
    id="WebApp_ID" 
    version="2.5">
  <display-name>Some Minimal Webapp</display-name>
  <welcome-file-list>   
    <welcome-file>index.jsp</welcome-file>    
  </welcome-file-list>

  <servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>
      org.springframework.web.servlet.DispatcherServlet
    </servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>*.do</url-pattern>
  </servlet-mapping>
</web-app>

créer un fichier appelé dispatcher-servlet.xml et le stocker sous WEB-INF . Depuis que nous avons mentionné index.jsp dans la liste de bienvenue, ajouter ce fichier sous WEB-INF .

dispatcher-servlet.xml

Dans le dispatcher-servlet.xml définir vos haricots:

<?xml version="1.0" encoding="UTF-8"?>
<beans 
    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd     
        http://www.springframework.org/schema/context     
        http://www.springframework.org/schema/context/spring-context.xsd">

    <bean id="bean1">
      ...
    </bean>
    <bean id="bean2">
      ...
    </bean>         

    <context:component-scan base-package="com.example" />
    <!-- Import your other configuration files too -->
    <import resource="other-configs.xml"/>
    <import resource="some-other-config.xml"/>

    <!-- View Resolver -->
    <bean 
        id="viewResolver" 
        class="org.springframework.web.servlet.view.UrlBasedViewResolver">
      <property 
          name="viewClass" 
          value="org.springframework.web.servlet.view.JstlView" />
      <property name="prefix" value="/WEB-INF/jsp/" />
      <property name="suffix" value=".jsp" />
    </bean>
</beans>

pour une application simple de ressort, vous n'avez pas à définir ContextLoaderListener dans votre web.xml ; vous pouvez simplement mettre tous vos fichiers de configuration de ressort dans <servlet> :

<servlet>
    <servlet-name>hello</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:spring/mvc-core-config.xml, classpath:spring/business-config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

pour une application de ressort plus complexe, où vous avez plusieurs DispatcherServlet définis, vous pouvez avoir les fichiers de configuration de ressort communs qui sont partagés par tous les DispatcherServlet définis dans le ContextLoaderListener :

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:spring/common-config.xml</param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<servlet>
    <servlet-name>mvc1</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:spring/mvc1-config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet>
    <servlet-name>mvc2</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:spring/mvc2-config.xmll</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

il suffit de garder à l'esprit, ContextLoaderListener effectue le travail d'initialisation réel pour le contexte d'application root .

j'ai trouvé cet article aide beaucoup: MVC printemps-contexte D'Application vs contexte D'Application Web

Le blog, " But de ContextLoaderListener – Spring MVC " donne une très bonne explication.

selon lui, les contextes D'Application sont hiérarchisés et donc le contexte de Dispatchererlvet devient l'enfant du contexte de Contextloaderlistener's. En raison de cela, la technologie utilisée dans la couche de contrôle (Struts ou MVC de ressort) peut être indépendante du contexte root créé ContextLoaderListener.

lorsque vous voulez mettre votre fichier Servlet dans votre emplacement personnalisé ou avec un nom personnalisé, plutôt que la convention de nommage par défaut [servletname]-servlet.xml et le chemin sous Web-INF/ , alors vous pouvez utiliser ContextLoaderListener .

ContextLoaderListner est un écouteur Servlet qui charge tous les fichiers de configuration (configuration de la couche service, Configuration de la couche persistance, etc.) dans un contexte d'application à ressort unique.

cela aide à diviser les configurations de ressorts en plusieurs fichiers XML.

une fois les fichiers de contexte chargés, Spring crée un objet WebApplicationContext basé sur la définition de bean et le stocke dans le ServletContext de votre web application.

fondamentalement, vous pouvez isoler votre contexte d'application racine et le contexte d'application web en utilisant ContextLoaderListner.

le fichier de configuration mappé avec le contexte param se comportera comme une configuration de contexte d'application racine. Et le fichier de configuration mappé avec le servlet de répartiteur se comportera comme le contexte d'application web.

dans n'importe quelle application web, nous pouvons avoir plusieurs servlets de répartiteur, donc plusieurs contextes d'application web.

Mais dans n'importe quelle application web, nous pouvons n'avoir qu'un seul contexte d'application racine qui est partagé avec tous les contextes d'application web.

nous devrions définir nos services communs, entités, aspects, etc. dans le contexte de l'application racine. Et les contrôleurs, intercepteurs etc sont dans le contexte de l'application web pertinente.

un échantillon de toile.xml est

<!-- language: xml -->
<web-app>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <context-param>
        <param-name>contextClass</param-name>
        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </context-param>
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>example.config.AppConfig</param-value>
    </context-param>
    <servlet>
        <servlet-name>restEntryPoint</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextClass</param-name>
            <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
        </init-param>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>example.config.RestConfig</param-value>
        </init-param>       
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>restEntryPoint</servlet-name>
        <url-pattern>/rest/*</url-pattern>
    </servlet-mapping>
    <servlet>
        <servlet-name>webEntryPoint</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextClass</param-name>
            <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
        </init-param>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>example.config.WebConfig</param-value>
        </init-param>       
        <load-on-startup>1</load-on-startup>
    </servlet>  
    <servlet-mapping>
        <servlet-name>webEntryPoint</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

</web-app> 

voici un exemple de classe de configuration.config.AppConfig peut être utilisé pour configurer des services, des entités, des aspects etc dans le contexte de l'application racine qui sera partagée avec tous les autres contextes d'application web (par exemple ici, nous avons deux classes de config RestConfig et WebConfig)

PS: ici ContextLoaderListener est complètement optionnel. Si nous ne mentionnerons pas ContextLoaderListener dans web.xml ici, AppConfig ne fonctionnera pas. Dans ce cas, nous devons configurer tous nos services et entités dans WebConfig et Rest Config.

il vous donnera point de crochet pour mettre quelque code que vous souhaitez être exécuté sur le temps de déploiement de l'application web

cet auditeur Bootstrap doit démarrer et arrêter le root WebApplicationContext de Spring. Comme une application web peut avoir plusieurs servlet de répartiteur et chacun ayant son propre contexte d'application contenant des contrôleurs, le résolveur de vue, mappages de gestionnaire, etc mais vous pourriez vouloir avoir des haricots de service, des haricots DAO dans le contexte d'application racine et vouloir utiliser dans tout le contexte d'application enfant(contexte d'application créé par servlets dispatcher).

2ème utilisation de cet écouteur est quand vous voulez utiliser le printemps de sécurité.

Votre compréhension est correcte. Je me demande pourquoi vous ne voyez aucun avantage à ContextLoaderListener. Par exemple, vous devez construire une session factory (pour gérer la base de données). Cette opération peut prendre un certain temps, il est donc préférable de le faire au démarrage. Bien sûr, vous pouvez le faire avec des servlets d'initialisation ou autre chose, mais L'avantage de L'approche de Spring est que vous faites la configuration sans code d'écriture.

si on écrit web.xml sans ContextLoaderListener puis nous ne pouvons pas donner l'authentification en utilisant customAuthenticationProvider dans la sécurité de printemps. Comme DispatcherServelet est le contexte enfant de ContextLoaderListener, customAuthenticationProvider est la partie du contexteparent qui est ContextLoaderListener. Le contexte parental ne peut donc pas avoir les dépendances du contexte de l'enfant. Et donc, il est préférable d'écrire printemps-contexte.xml dans contextparam au lieu de l'écrire dans l'initparam.

je crois que son utilisation réelle vient quand vous voulez avoir plus d'un des fichiers de configuration ou vous avez xyz.xml fichier au lieu de applicationcontext.xml pour eg

<context-param><param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/training-service.xml, /WEB-INF/training-data.xml</param-value> </context-param>

une autre approche de ContextLoaderListener est D'utiliser ContextLoaderServlet comme ci-dessous

<servlet> <servlet-name>context</servlet-name> <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet>

Classe D'Écoute - écoute un événement (p. ex.. Serveur de démarrage/arrêt)

ContextLoaderListener -

1. écoute pendant le démarrage/l'arrêt du serveur
2. prend les fichiers de configuration du ressort en entrée et crée les fèves selon la configuration et les prépare (détruit la fève pendant l'arrêt)

3. les fichiers de Configuration peuvent être fournis comme ceci dans web.xml

   <param-name>contextConfigLocation</param-name>  
   <param-value>/WEB-INF/dispatcher-servlet.xml</param-value>  
   

dans le contexte de spring framework but de ContextLoaderListener est de charger les autres haricots dans votre application tels que les composants de niveau intermédiaire et de données qui entraînent le dos de l'application.