web-dev-qa-db-fra.com

Différence entre applicationContext.xml et spring-servlet.xml dans Spring Framework

  • Est-ce que applicationContext.xml et spring-servlet.xml sont liés de toute façon dans Spring Framework?
  • Les fichiers de propriétés déclarés dans applicationContext.xml seront-ils disponibles pour DispatcherServlet?
  • Dans le même ordre d'idées, pourquoi ai-je besoin d'un *-servlet.xml? Pourquoi applicationContext.xml seul est-il insuffisant?
javaspring
354
user448070

Spring vous permet de définir plusieurs contextes dans une hiérarchie parent-enfant.

Le applicationContext.xml définit les beans du "contexte de la webapp racine", c’est-à-dire le contexte associé à la webapp.

Le spring-servlet.xml (ou ce que vous appelez autrement) définit les beans pour le contexte d'application d'un servlet. Il peut y en avoir beaucoup dans une application Web, une par servlet Spring (par exemple, spring1-servlet.xml pour la servlet spring1, spring2-servlet.xml pour la servlet spring2).

Les beans dans spring-servlet.xml peuvent référencer des beans dans applicationContext.xml, mais pas l'inverse.

Tous les contrôleurs Spring MVC doivent aller dans le contexte spring-servlet.xml.

Dans la plupart des cas simples, le contexte applicationContext.xml n'est pas nécessaire. Il est généralement utilisé pour contenir des beans partagés entre tous les servlets d'une application Web. Si vous n'avez qu'un seul servlet, alors il n'y a pas vraiment d'intérêt, à moins que vous n'ayez un usage spécifique.

418
skaffman

Scénario 1

Dans une application client (l'application n'est pas une application Web, par exemple, une application pivotante)

private static ApplicationContext context = new  ClassPathXmlApplicationContext("test-client.xml");

context.getBean(name);

Pas besoin de web.xml . ApplicationContext en tant que conteneur pour obtenir un service de bean. Pas besoin de conteneur de serveur Web. Dans test-client.xml , il peut exister un bean simple sans accès distant, un bean avec accès distant.

Conclusion: Dans le scénario 1, applicationContext et DispatcherServlet ne sont pas liés.

Scénario 2

Dans une application serveur (application déployée sur un serveur, par exemple Tomcat). Accès au service via un accès distant à partir du programme client (par exemple, application Swing)

Définir un auditeur dans web.xml 

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

Au démarrage du serveur, ContextLoaderListener instancie les beans définis dans applicationContext.xml .

En supposant que vous ayez défini les éléments suivants dans applicationContext.xml :

<import resource="test1.xml" />
<import resource="test2.xml" />
<import resource="test3.xml" />
<import resource="test4.xml" />

Les beans sont instanciés à partir des quatre fichiers de configuration test1.xml , test2.xml , test3.xml , test4.xml .

Conclusion: Dans le scénario 2, applicationContext et DispatcherServlet ne sont pas liés.

Scénario 3

Dans une application Web avec Spring MVC.

Dans web.xml définissez:

<servlet>
    <servlet-name>springweb</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>    
</servlet>

<servlet-mapping>
    <servlet-name>springweb</servlet-name>
    <url-pattern>*.action</url-pattern>
</servlet-mapping>

Lorsque Tomcat démarre, les beans définis dans , springweb-servlet.xml sont instanciés. DispatcherServlet étend FrameworkServlet. Dans FrameworkServlet, l'instanciation de haricot a lieu pour springweb. Dans notre cas , springweb est FrameworkServlet.

Conclusion: Dans le scénario 3, applicationContext et DispatcherServlet ne sont pas liés.

Scénario 4

Dans l'application Web avec le printemps MVC. springweb-servlet.xml pour servlet et applicationContext.xml pour accéder à la service commercial dans le programme serveur ou pour accéder au service de base de données dans un autre programme serveur.

Dans web.xml , les éléments suivants sont définis:

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<servlet>
    <servlet-name>springweb</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

</servlet>

<servlet-mapping>
    <servlet-name>springweb</servlet-name>
    <url-pattern>*.action</url-pattern>
</servlet-mapping>

Au démarrage du serveur, ContextLoaderListener instancie les beans définis dans applicationContext.xml ; en supposant que vous ayez déclaré ceci:

<import resource="test1.xml" />
<import resource="test2.xml" />
<import resource="test3.xml" />
<import resource="test4.xml" />

Les beans sont tous instanciés à partir des quatre test1.xml , test2.xml , test3.xml , test4.xml . Après l'achèvement de l'instanciation du bean définie dans applicationContext.xml , puis sur les beans définis dans , springweb-servlet.xml sont instanciés.

Donc, l'ordre d'instanciation est root, c'est le contexte de l'application, puis FrameworkServlet.

Maintenant, il est clair pourquoi ils sont importants dans quel scénario.

101
abishkar bhattarai

Un dernier point que je veux ajouter. Dans spring-servlet.xml, nous incluons l'analyse des composants pour le package de contrôleurs. Dans l'exemple suivant, nous incluons une annotation de filtre pour le package du contrôleur.

<!-- Scans for annotated @Controllers in the classpath -->
<context:component-scan base-package="org.test.web" use-default-filters="false">
    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

Dans applicationcontext.xml, nous ajoutons un filtre pour le paquet restant à l'exclusion du contrôleur.

<context:component-scan base-package="org.test">
        <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
    </context:component-scan>
53
Raje

En des mots simples,

applicationContext.xml définit les beans partagés par tous les servlets. Si votre application a plusieurs servlets, la définition des ressources communes dans le applicationContext.xml aurait plus de sens.

spring-servlet.xml définit les beans uniquement liés à ce servlet. Ici c'est la servlet de dispatcheur. Donc, vos contrôleurs Spring MVC doivent être définis dans ce fichier.

Il n'y a rien de mal à définir tous les beans dans le spring-servlet.xml si vous n'exécutez qu'un seul servlet dans votre application Web.

10
Krishna

Dans la technologie Servlet, si vous souhaitez transmettre une entrée à un servlet particulier, vous devez transmettre init param comme ci-dessous le code.

 <servlet>
    <servlet-name>DBController</servlet-name>
    <servlet-class>com.test.controller.DBController</servlet-class>
    <init-param>
        <param-name>username</param-name>
        <param-value>John</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>DBController</servlet-name>
    <url-pattern>/DBController</url-pattern>
</servlet-mapping>

Si vous souhaitez transmettre des paramètres communs à tous les servlets, vous devez configurer le paramètre context. Exemple

 <context-param>
    <param-name>email</param-name>
    <param-value>[email protected]</param-value>
</context-param>

Tellement exactement comme cela lorsque nous travaillons avec Spring MVC, nous devons fournir des informations au servlet prédéfini fourni par Spring qui est DispatcherServlet via init param. Donc, la configuration est comme jachères, nous fournissons ici le paramètre spring-servlet.xml en tant que paramètre init à DispatcherServlet.

 <?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_3_0.xsd"
    id="WebApp_ID" version="3.0">
    <display-name>Spring MVC App</display-name>

    <servlet>
        <servlet-name>SpringController</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/spring-servlet.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>SpringController</servlet-name>
        <url-pattern>*.htm</url-pattern>
    </servlet-mapping>
</web-app>

Encore une fois, nous avons besoin de param context. Cela est applicable pour toute application. Nous pouvons donc fournir le contexte racine qui est applicationcontext.xml. La configuration est la suivante:

    <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/applicationcontext.xml</param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<servlet>
        <servlet-name>SpringController</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/spring-servlet.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>SpringController</servlet-name>
        <url-pattern>*.htm</url-pattern>
    </servlet-mapping>
5
Rajanikanta Pradhan

Les contextes d'application fournissent un moyen de résoudre les messages texte, y compris la prise en charge de l'un de ces messages. Les contextes d'application fournissent un moyen générique de charger des ressources de fichier, telles que des images. Les contextes d'application peuvent publier des événements sur des beans enregistrés en tant qu'écouteurs. Certaines opérations sur le conteneur ou les haricots dans le conteneur, qui doivent être gérées de manière programmatique avec une usine de haricots, peuvent être gérées de manière déclarative dans un contexte d'application. Prise en charge de ResourceLoader: L’interface Spring de Resource utilise une abstraction générique flexible pour la gestion des ressources de bas niveau. Un contexte d'application lui-même est un ResourceLoader. Par conséquent, une application a accès à des instances de ressources spécifiques au déploiement. Prise en charge de MessageSource: le contexte d'application implémente MessageSource, une interface utilisée pour obtenir des messages localisés, l'implémentation réelle étant connectable.

4
Sujata