Rôle/Objet de ContextLoaderListener au Printemps?

Je suis en train d'apprendre Framework Spring qui est utilisé dans mon projet. J'ai trouvé le ContextLoaderListener entrée dans ma web.xml fichier. Mais ne pouvait pas comprendre comment exactement il permet à un développeur?

Dans la documentation officielle de ContextLoaderListener il dit que c'est pour commencer WebApplicationContext. Concernant WebApplicationContext JavaDocs dire:

Interface pour permettre la configuration d'une application web.

Mais je ne suis pas en mesure de comprendre ce que je veux réaliser avec ContextLoaderListener en interne qui initialise le WebApplicationContext ?

Selon ma compréhension, ContextLoaderListener lit le fichier de configuration Spring (avec la valeur donnée contre contextConfigLocation dans web.xml), l'analyse et les charges de la singleton bean définie dans ce fichier de configuration. De la même manière quand on veut charger prototype bean, nous allons utiliser la même webapplication contexte pour le charger. Nous avons donc initialiser la webapplication avec ContextLoaderListener de sorte que nous pouvons lire/analyser/valider le fichier de configuration à l'avance et à chaque fois que l'on veut injecter de la dépendance, nous pouvons d'emblée le faire sans délai. Est-ce la compréhension correcte?

quelqu'un peut-il me faire savoir la différence entre RequestContextListener et ContextLoaderListener

InformationsquelleAutor M Sach | 2012-08-05

103

Votre compréhension est correcte. Le ApplicationContext est l'endroit où vos beans Spring live. Le but de la ContextLoaderListener est double:
1. pour attacher le cycle de vie de la ApplicationContext pour le cycle de vie de la ServletContext et
2. pour automatiser la création de l' ApplicationContext, de sorte que vous n'avez pas à écrire de code explicite faire la créer c'est une fonction de commodité.
Une autre commode chose à propos de la ContextLoaderListener est qu'il crée un WebApplicationContext et WebApplicationContext permet d'accéder à la ServletContext via ServletContextAware les haricots et les getServletContext méthode.
- J'ai un doute concernant votre deuxième point. Vous avez dit ServletContextListener donne accès à ServletContext. Mais, même si web.xml n'a pas ServletContextListener, ServletContext peut être consulté par le biais de WebApplicationContext (WebApplicationContext est autocâblés). Alors, que faut-il exactement liée à ServletContext?
- Il crée le WebApplicationContext. Sinon, il aurait besoin de créer manuellement.
- ne ContextLoaderListener de mettre en œuvre une méthode destroy de détruire tous les haricots lorsque le conteneur web s'arrête?
- oui - ce n'est que lorsque contextDestroyed est appelé. Voir les docs de l'API.
- J'ai un doute après la lecture de ce que j'ai vérifié mes applications web.xml. Dans mon fichier xml, il y a deux auditeurs ContextLoaderListener et DispatcherServlet. Donc je suppose qu'il n'est pas nécessaire de les deux, est-il sécuritaire de supprimer ContextLoaderListener pourquoi je demande car l'application en direct depuis 7-8 mois. web.xml ici pour votre référence.
InformationsquelleAutor sourcedelica

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

Voici à quoi ça ressemblera:

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 de le stocker sous WEB-INF. Depuis que nous avons mentionnés index.jsp d'accueil de la liste, 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>

Si elle est facultative, et quand souhaitez-vous voulez pour l'utiliser? Il semble que le Printemps de la Sécurité l'exige l'utilisation de la DelegatingFilterProxy.
Vous avez de l'utiliser lorsque vous voulez mettre votre Servlet fichier dans votre emplacement personnalisé ou avec nom personnalisé, plutôt que de le nom par défaut "[servlet-name]-servlet.xml" et le chemin d'accès en vertu de la "Web-INF/"
Est-ce une bonne idée de définir haricot dispatcher-servlet.xml que applicationContext.xml?
Habituellement, il est préférable de répartir les haricots en reflétant les couches de l'architecture de votre application. Les haricots pour la couche de présentation (par exemple des contrôleurs mvc) peut être dispatcher-servlet.xml. Haricots appartenant à la couche de service doit être défini applicationContext.xml. Ce n'est pas une règle stricte, mais c'est une bonne pratique pour réaliser la séparation des préoccupations.
Karna je ne pense pas que c'est nécessaire pour le nom et changement d'emplacement. Je pense que c'est nécessaire quand nous sommes initialisation de plusieurs Répartiteur de servlets et veulent toujours une Racine de contexte partagé par tous DispaterServlets propre contexte, puis nous avons besoin d'utiliser ContextLoaderListener.

InformationsquelleAutor Vikram

Pour un simple Ressort de l'application, vous n'avez pas à définir ContextLoaderListener dans votre web.xml; vous pouvez simplement mettre tous vos Printemps des fichiers de configuration 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>

De plus en plus complexes, le Printemps de l'application, où vous avez plusieurs DispatcherServlet défini, vous pouvez avoir de la commune de Printemps fichiers de configuration qui sont partagées 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 réalise l'initialisation de travail pour la racine contexte de l'application.

J'ai trouvé cet article qui aide beaucoup:
Spring MVC – Contexte de l'Application vs Contexte d'Application Web

l'article partagé ici vraiment s'assure de la compréhension profonde des concepts

InformationsquelleAutor xli

10

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

Selon elle, l'Application Contextes sont hierarchial et donc DispatcherSerlvet du contexte devient l'enfant de ContextLoaderListener du contexte. En raison de ce qui, la technologie utilisée dans la couche contrôleur Struts ou Spring MVC) peut indépendante de la racine de contexte créé ContextLoaderListener.
- Merci pour le partage de mon pote.. 🙂
InformationsquelleAutor Dileepa
3

Lorsque vous voulez mettre votre Servlet fichier dans votre emplacement personnalisé ou avec nom personnalisé, plutôt que la valeur par défaut convention de nommage [servletname]-servlet.xml et le chemin d'accès en vertu de Web-INF/ ,alors vous pouvez utiliser ContextLoaderListener.

InformationsquelleAutor Dungeon_master
3

ContextLoaderListner est un Servlet auditeur qui se charge de tous les différents fichiers de configuration (service de configuration de la couche, la couche de persistance de configuration, etc) en un seul printemps contexte de l'application.

Cela permet de diviser le printemps des configurations sur plusieurs fichiers XML.

Une fois le contexte fichiers sont chargés, Printemps crée un WebApplicationContext objet basé sur le haricot définition et la stocke dans le ServletContext de votre application web.

InformationsquelleAutor Prashant_M

Fondamentalement, vous pouvez isoler votre racine de contexte de l'application et du contexte d'application web à l'aide de ContextLoaderListner.

Le fichier de configuration mappé avec le contexte param va se comporter comme racine de contexte de l'application de configuration. Et le fichier config mappé avec répartiteur de servlet va se comporter comme contexte d'application web.

Dans n'importe quelle application web que nous pouvons avoir plusieurs répartiteur de servlets, afin de multiples application web contextes.

Mais dans n'importe quelle application web que nous pouvons avoir qu'une seule racine de contexte de l'application qui est partagé avec toutes les application web contextes.

Nous devons définir notre commune, les services, les entités, les aspects etc dans la racine de contexte de l'application. Et les contrôleurs, les intercepteurs etc sont pertinentes dans le contexte de l'application web.

Un échantillon web.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>

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

PS: Ici ContextLoaderListener est totalement facultatif. Si nous ne mentionnerons pas les ContextLoaderListener dans web.xml ici, AppConfig ne fonctionnera pas. Dans ce cas, il est nécessaire de configurer l'ensemble de nos services et entités dans le WebConfig et le Reste de la Config.

InformationsquelleAutor Anil Agrawal

2

Cette amorce de l'écouteur est de démarrage et d'arrêt du Printemps racine WebApplicationContext. Une application web peut avoir plusieurs répartiteur de servlet et chacun ayant son propre contexte de l'application contenant des contrôleurs, vue résolveur, mappages de gestionnaires, etc, Mais vous pouvez avoir un service de haricots, de DAO les haricots dans la racine de contexte de l'application et que vous souhaitez utiliser dans tous les enfant de contexte de l'application(application de contexte créé par le dispatcher les servlets).

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

InformationsquelleAutor rulhaniam
1

Il vous donnera un point de crochet pour mettre un peu de code que vous voulez exécuter sur l'heure du déploiement de l'application web
- Jigar, en fait c'est ce que je suis en train de le découvrir.Quelle est la fonction , contexte par défaut chargeur de classe au moment du déploiement?
- Modification des propriétés ou des fichiers xml et de les laisser être rechargée au dernier moment sans avoir à redémarrer le serveur
InformationsquelleAutor Jigar Joshi
0

Votre compréhension est correcte. Je me demande pourquoi vous ne voyez pas d'avantages dans ContextLoaderListener. Par exemple, vous avez besoin pour construire une fabrique de session (pour gérer la base de données). Cette opération peut prendre un certain temps, de sorte qu'il est mieux de le faire au démarrage. Bien sûr, vous pouvez le faire avec l'init des servlets ou quelque chose d'autre, mais l'avantage du Printemps approche, c'est que vous faites de configuration sans avoir à écrire de code.

InformationsquelleAutor evg
0

Si nous écrire web.xml sans ContextLoaderListener alors nous ne pouvons pas donner la athuntication à l'aide de customAuthenticationProvider au printemps de sécurité. Parce que DispatcherServelet est l'enfant du contexte de ContextLoaderListener, customAuthenticationProvider est la partie de parentContext qui est ContextLoaderListener. Afin Contexte parent ne peut pas avoir les dépendances de l'enfant contexte. Et donc, il est préférable d'écrire spring-context.xml dans contextparam plutôt que de l'écrire dans le initparam.

InformationsquelleAutor SathishSakthi
0

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 exemple

<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 à l'aide de 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>

InformationsquelleAutor user666
0

Classe écouteur - Écoute sur un événement (par exemple.. Serveur de démarrage/arrêt)

ContextLoaderListener -
1. Écoute durant le serveur de démarrage/arrêt
2. Prend le Printemps des fichiers de configuration en entrée et crée les haricots selon la configuration et le rendre prêt (détruit les haricots pendant l'arrêt)
3. Les fichiers de Configuration peuvent être fournis comme cela dans web.xml
```
<param-name>contextConfigLocation</param-name>  
<param-value>/WEB-INF/dispatcher-servlet.xml</param-value>  
```
InformationsquelleAutor bharanitharan
0

Dans le cadre du framework spring but de ContextLoaderListener est à la charge de l'autre les haricots dans votre application, tels que la couche intermédiaire et de la couche de données de composants que le lecteur de la fin de l'application.

InformationsquelleAutor Salahin Rocky

Vous devez vous connecter pour publier un commentaire.