Quelle est la différence entre ApplicationContext et WebApplicationContext dans Spring MVC ?

Question

Quelle est la différence entre le contexte d'application et le contexte d'application Web ?

Je suis conscient que WebApplicationContext est utilisé pour les applications orientées architecture Spring MVC ?

Je veux savoir à quoi sert ApplicationContext dans les applications MVC ? Et quel type de beans sont définis dans ApplicationContext ?

Answer 1

Le contexte d'application étendu de l'application Web est conçu pour fonctionner avec le contexte standard de l'application Web. javax.servlet.ServletContext afin qu'il puisse communiquer avec le conteneur.

public interface WebApplicationContext extends ApplicationContext {
    ServletContext getServletContext();
}

Les beans, instanciés dans WebApplicationContext, pourront également utiliser ServletContext s'ils implémentent l'interface ServletContextAware.

package org.springframework.web.context;
public interface ServletContextAware extends Aware { 
     void setServletContext(ServletContext servletContext);
}

Il est possible de faire beaucoup de choses avec l'instance ServletContext, par exemple accéder aux ressources WEB-INF (configs xml, etc.) en appelant la méthode getResourceAsStream(). Généralement, tous les contextes d'application définis dans le fichier web.xml d'une application Spring à base de servlets sont des contextes d'application Web, ce qui vaut aussi bien pour le contexte webapp racine que pour le contexte app de la servlet.

De plus, le fait de dépendre des capacités du contexte de l'application web peut rendre votre application un peu plus difficile à tester, et vous devrez peut-être utiliser MockServletContext pour les tests.

Différence entre servlet et contexte Root Spring vous permet de construire des hiérarchies de contexte d'application à plusieurs niveaux, de sorte que le bean requis sera récupéré dans le contexte parent s'il n'est pas présent dans le contexte d'application actuel. Dans les applications Web, il existe par défaut deux niveaux de hiérarchie, les contextes Root et Servlet : .

Cela vous permet d'exécuter certains services en tant que singletons pour l'ensemble de l'application (les beans de sécurité de Spring et les services d'accès aux bases de données de base résident généralement ici) et d'autres en tant que services séparés dans les servlets correspondants pour éviter les conflits de noms entre les beans. Par exemple, un contexte de servlet servira les pages web et un autre implémentera un service web sans état.

Cette séparation à deux niveaux existe d'emblée lorsque vous utilisez les classes de servlets de Spring : pour configurer le contexte d'application Root, vous devez utiliser les éléments suivants Paramètre de contexte dans votre web.xml

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/root-context.xml
            /WEB-INF/applicationContext-security.xml
    </param-value>
</context-param>

(le contexte de l'application racine est créé par ContextLoaderListener qui est déclaré dans web.xml

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

) et servlet pour les contextes d'application des servlets

<servlet>
   <servlet-name>myservlet</servlet-name>
   <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
   <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>app-servlet.xml</param-value>
   </init-param>
</servlet>

Veuillez noter que si init-param est omis, alors spring utilisera myservlet-servlet.xml dans cet exemple.

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

Answer 2

La réponse acceptée est "par", mais il existe une explication officielle à ce sujet :

Le WebApplicationContext est une extension de l'ApplicationContext ordinaire qui possède certaines caractéristiques supplémentaires nécessaires aux applications Web. Il diffère d'un ApplicationContext normal en ce qu'il est capable de résoudre des thèmes (voir Utilisation des thèmes), et qu'il sait à quelle Servlet il est associé (en ayant un lien avec le ServletContext). Le WebApplicationContext est lié au ServletContext, et en utilisant les méthodes statiques de la classe RequestContextUtils, vous pouvez toujours rechercher le WebApplicationContext si vous devez y accéder.

Cité dans Référence au cadre web de Spring

D'ailleurs, la servlet et le contexte Root sont les deux webApplicationContext :

Answer 3

Si l'on revient à l'époque des servlets, le fichier web.xml ne peut avoir qu'une seule <context-param> Ainsi, un seul objet de contexte est créé lorsque le serveur charge une application et les données de ce contexte sont partagées entre toutes les ressources (ex : Servlets et JSPs). C'est la même chose que d'avoir le nom du pilote de la base de données dans le contexte, qui ne changera pas. De la même manière, lorsque nous déclarons le paramètre contextConfigLocation dans l'objet <contex-param> Spring crée un objet Contexte d'application.

 <context-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>com.myApp.ApplicationContext</param-value>
 </context-param>

Vous pouvez avoir plusieurs Servlets dans une application. Par exemple, vous pouvez vouloir traiter les demandes /secure/* d'une certaine manière et /non-seucre/* d'une autre manière. Pour chacune de ces servlets, vous pouvez avoir un objet contextuel, qui est un WebApplicationContext.

<servlet>
    <servlet-name>SecureSpringDispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextClass</param-name>
        <param-value>com.myapp.secure.SecureContext</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>SecureSpringDispatcher</servlet-name>
    <url-pattern>/secure/*</url-pattern>
</servlet-mapping>
<servlet>
    <servlet-name>NonSecureSpringDispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextClass</param-name>
        <param-value>com.myapp.non-secure.NonSecureContext</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>NonSecureSpringDispatcher</servlet-name>
    <url-pattern>/non-secure/*</url-patten>
</servlet-mapping>

Answer 4

ApplicationContext (Contexte d'application racine) : Chaque application web Spring MVC possède un fichier applicationContext.xml qui est configuré comme la Racine de la configuration du contexte. Spring charge ce fichier et crée un applicationContext pour l'ensemble de l'application. Ce fichier est chargé par le ContextLoaderListener qui est configuré comme un paramètre de contexte dans le fichier web.xml. Et il n'y aura qu'un seul applicationContext par application web.

WebApplicationContext : WebApplicationContext est un contexte d'application web aware, c'est-à-dire qu'il possède des informations sur le contexte des servlets. Une seule application web peut avoir plusieurs WebApplicationContext et chaque servlet Dispatcher (qui est le contrôleur frontal de l'architecture Spring MVC) est associé à un WebApplicationContext. Le fichier de configuration webApplicationContext *-servlet.xml est spécifique à un DispatcherServlet. Et comme une application web peut avoir plus d'un dispatcher servlet configuré pour servir plusieurs requêtes, il peut y avoir plus d'un fichier webApplicationContext par application web.

Answer 5

Contexte de l'application Web spécifié par le WebApplicationContext est un contexte d'application Spring pour les applications web. Il possède toutes les propriétés d'un contexte d'application Spring ordinaire, étant donné que l'interface WebApplicationContext étend l'interface ApplicationContext et ajoutez une méthode permettant de récupérer l'API standard des servlets. ServletContext pour l'application web.

En plus des champs d'application standard de Spring bean singleton y prototype Dans le contexte d'une application Web, trois autres champs d'application sont disponibles :

• request - étend une définition de bean unique au cycle de vie d'une requête HTTP unique ; c'est-à-dire que chaque requête HTTP possède sa propre instance de bean créée à partir d'une définition de bean unique.
• session - étend la définition d'un seul bean au cycle de vie d'une session HTTP.
• application - étend la définition d'un seul bean au cycle de vie d'un projet de ServletContext