Différence entre applicationContext.xml et spring-servlet.xml au Printemps

Question

Sont - applicationContext.xml et spring-servlet.xml liés, de toute façon, dans le cadre du printemps? Va les propriétés des fichiers déclarés en applicationContext.xml être disponible à l' DispatcherServlet? Sur une note connexe, pourquoi ai-je besoin d'un *-servlet.xml ? Pourquoi est - applicationContext.xml seul insuffisant?

Answer 1

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

L' applicationContext.xml définit les fèves pour la "racine de la webapp contexte", c'est à dire le contexte associé à la webapp.

L' spring-servlet.xml (ou ce que vous voulez l'appeler) définit les fèves pour une servlet de l'application de contexte. Il peut y avoir un grand nombre de ces dans une webapp, l'un par Ressort de servlet (par exemple, spring1-servlet.xml pour servlet spring1, spring2-servlet.xml pour servlet spring2).

Les haricots en spring-servlet.xml peut faire référence à des haricots en applicationContext.xml, mais pas vice-versa.

Tous les contrôleurs Spring MVC doit aller dans l' spring-servlet.xml contexte.

Dans la plupart des cas simples, l' applicationContext.xml contexte est inutile. Il est généralement utilisé pour contenir les fèves, qui sont partagés entre tous les servlets dans une webapp. Si vous avez seulement une servlet, alors il n'y a pas vraiment beaucoup de point, sauf si vous avez une utilisation spécifique.

Answer 2

Scenario1. Dans l'application client(application n'est pas une application web.E.g peut être swing app) private static ApplicationContext context = new ClassPathXmlApplicationContext("test-client.xml");

context.getBean(name);

Pas besoin de web.xml.ApplicationContext comme conteneur pour l'obtention de haricot service.Pas besoin de serveur web conteneur. Dans test-client.xml il peut être Simple de haricot sans remoting,haricot avec l'accès distant. Conclusion:Dans Scenario1 applicationContex et DispatcherServlet ils ne sont pas liés.

Scénario 2. Le serveur d'application(application déployée dans le serveur d'e.g tomcat).Consulté le service via l'accès distant à partir d'un programme client(e.g swing app)

Définir auditeur dans web.xml

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

Lors du démarrage du serveur ContextLoaderListener instancie les haricots définis dans applicationcontext.xml. Si il y a supposer

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

les haricots sont instanciés à partir de tous les quatre test1.xml,test2.xml,test3.xml,test4.xml. Conclusion:Dans le Scénario 2 applicationContex et DispatcherServlet ils ne sont pas liés.

Scenario3.Dans l'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 commence bean défié dans springweb-servlet.xml est instancié. DispatcherServlet s'étend FrameworkServlet.Dans FrameworkServlet bean instanciation prend place pour springweb .Dans notre cas springweb est FrameworkServlet.

Conclusion:Dans Scenario3 applicationContex et DispatcherServlet ils ne sont pas liés.

Scenario4.Dans l'application web avec spring MVC.springweb-servlet.xml pour servlet et applicationcontext.xml pour accéder au service de l'entreprise dans le programme serveur, Ou pour accéder à la DB de service dans un autre programme serveur.Dans web.xml définissez.

org.springframework.web.contexte.ContextLoaderListener

<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>

Lors du démarrage du serveur ContextLoaderListener instancie les haricots définis dans applicationcontext.xml Si il y a supposer

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

les haricots sont tous instanciés à partir de tous les quatre test1.xml,test2.xml,test3.xml,test4.xml. Après l'achèvement de haricot instanciation défini dans applicationcontext puis bean défié dans springweb-servlet.xml est instancié. Donc l'instanciation d'ordre est à la racine de contexte de l'application ,puis FrameworkServlet.

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

Answer 3

Un point de plus je tiens à ajouter. En spring-servlet.xml nous inclure les composants de l'analyse pour l'ensemble de Contrôleur. Dans l'exemple suivant, nous incluons filtre d'annotation pour l'ensemble de contrôleur.

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

En applicationcontext.xml nous ajouter un filtre pour le reste de paquet à l'exclusion de contrôleur.

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

Answer 4

Application des contextes de fournir un moyen permettant de résoudre les messages texte, y compris le soutien pour l'i18n de ces messages. Application des contextes de fournir un moyen générique de charger le fichier de ressources, tels que des images. Application contextes peuvent publier des événements pour les fèves, qui sont enregistrées en tant qu'auditeurs. Certaines opérations sur le conteneur de grains dans le conteneur, qui doivent être traitées dans un programmatique de la mode avec un haricot usine, peuvent être traitées de façon déclarative dans un contexte d'application. ResourceLoader de soutien: le Printemps des Ressources de l'interface nous un flexible générique d'abstraction pour la manipulation à faible niveau de ressources. Un contexte d'application elle-même est un ResourceLoader, Donc fournit une application avec un accès à de déploiement spécifique des instances de Ressources. MessageSource de soutien: Le contexte de l'application implémente MessageSource, une interface utilisée pour obtenir les messages de localisation, avec la mise en œuvre réelle d'être enfichable