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

  • applicationContext.xml et spring-servlet.xml liés à Spring Framework?
  • Les fichiers de propriétés déclarés dans applicationContext.xml seront-ils disponibles pour DispatcherServlet ?
  • Sur une note connexe, pourquoi ai-je besoin d’un *-servlet.xml du tout? Pourquoi applicationContext.xml seul est-il insuffisant?

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

Le fichier applicationContext.xml définit les beans pour le “contexte Web racine”, c’est-à-dire le contexte associé à l’application Web.

Le spring-servlet.xml (ou autre chose que vous appelez) 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 servlet spring1 , spring2-servlet.xml pour 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 se trouver dans le contexte spring-servlet.xml .

Dans la plupart des cas simples, le contexte applicationContext.xml est inutile. 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’une seule servlet, il n’ya pas grand chose à faire, à moins que vous n’en ayez une utilisation spécifique.

Scénario 1

Dans l’application cliente (l’application n’est pas une application Web, par exemple, l’application peut être swing)

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

Pas besoin de web.xml . ApplicationContext en tant que conteneur pour obtenir le service bean. Pas besoin de conteneur de serveur Web. Dans test-client.xml, il peut y avoir un bean simple sans remoting, bean with remoting.

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 le serveur, par exemple Tomcat). Service accessible via la communication à distance depuis le programme client (par exemple, application Swing)

Définir un écouteur dans web.xml

  org.springframework.web.context.ContextLoaderListener  

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

En supposant que vous ayez défini ce qui suit dans applicationContext.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éfinir:

  springweb org.springframework.web.servlet.DispatcherServlet   springweb *.action  

Lorsque Tomcat démarre, les beans définis dans springweb-servlet.xml sont instanciés. DispatcherServlet étend FrameworkServlet . Dans FrameworkServlet instanciation du bean 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

En application web avec ressort MVC. springweb-servlet.xml pour servlet et applicationContext.xml pour accéder au service métier dans le programme serveur ou pour accéder au service de firebase database dans un autre programme serveur.

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

  org.springframework.web.context.ContextLoaderListener   springweb org.springframework.web.servlet.DispatcherServlet   springweb *.action  

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

     

Les beans sont tous instanciés à partir des quatre tests1.xml , test2.xml , test3.xml , test4.xml . Après l’achèvement de l’instanciation du bean définie dans applicationContext.xml, 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.

Un autre point que je veux append. Dans spring-servlet.xml nous incluons une parsing des composants pour le package Controller. Dans l’exemple suivant, nous incluons l’annotation du filtre pour le package du contrôleur.

     

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

    

En termes simples,

applicationContext.xml définit les beans partagés entre tous les servlets. Si votre application comporte plusieurs servlets, la définition des ressources communes dans le applicationContext.xml serait plus judicieuse.

spring-servlet.xml définit les beans liés uniquement à ce servlet. Ici c’est le servlet du répartiteur. Ainsi, 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 spring-servlet.xml qu’un seul servlet dans votre application Web.

Les contextes d’application fournissent un moyen de résoudre les messages texte, y compris la prise en charge de i18n de ces messages. Les contextes d’application fournissent un moyen générique de charger des ressources de fichiers, telles que des images. Les contextes d’application peuvent publier des événements sur des beans enregistrés comme écouteurs. Certaines opérations sur le conteneur ou les fèves dans le conteneur, qui doivent être traitées de manière programmatique avec une fabrique de haricots, peuvent être traitées de manière déclarative dans un contexte d’application. Prise en charge de ResourceLoader: Les ressources de Spring nous permettent d’interfacer une abstraction générique flexible pour gérer les ressources de bas niveau. Un contexte d’application lui-même est un ResourceLoader, donc fournit une application avec un access aux instances de ressources spécifiques au déploiement. Prise en charge de MessageSource: le contexte de l’application implémente MessageSource, une interface utilisée pour obtenir des messages localisés, l’implémentation réelle étant enfichable.

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

   DBController com.test.controller.DBController  username John  1   DBController /DBController  

Si vous souhaitez en transmettre quelques-unes, il est habituel de configurer les parameters de contexte. Exemple

   email admin@example.com  

Donc, exactement comme cela, quand nous travaillons avec Spring MVC, nous devons fournir certaines informations au servlet prédéfini fourni par Spring, à savoir DispatcherServlet via init param. Donc, la configuration est comme jachère, ici nous fournissons le paramètre spring-servlet.xml comme paramètre init à DispatcherServlet.

    Spring MVC App  SpringController org.springframework.web.servlet.DispatcherServlet  contextConfigLocation /WEB-INF/spring-servlet.xml  1   SpringController *.htm   

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

   contextConfigLocation /WEB-INF/applicationcontext.xml   org.springframework.web.context.ContextLoaderListener   SpringController org.springframework.web.servlet.DispatcherServlet  contextConfigLocation /WEB-INF/spring-servlet.xml  1   SpringController *.htm