Qual è la differenza tra ApplicationContext e WebApplicationContext in Spring MVC?

Qual è la differenza tra il contesto dell'applicazione e il contesto dell'applicazione Web?

Sono consapevole che WebApplicationContextviene utilizzato per le applicazioni orientate all'architettura Spring MVC?

Voglio sapere a cosa servono le ApplicationContextapplicazioni MVC? E in che tipo di fagioli sono definiti ApplicationContext?

Il contesto dell'applicazione Web ha esteso il contesto dell'applicazione progettato per funzionare con javax.servlet.ServletContext standard in modo che sia in grado di comunicare con il contenitore.

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

I bean, istanziati in WebApplicationContext saranno anche in grado di utilizzare ServletContext se implementano l'interfaccia ServletContextAware

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

Esistono molte cose da fare con l'istanza ServletContext, ad esempio l'accesso alle risorse WEB-INF (configurazioni XML e così via) chiamando il metodo getResourceAsStream (). In genere tutti i contesti di applicazione definiti in web.xml in un'applicazione Spring servlet sono contesti di applicazioni Web, questo va sia al contesto di webapp root che al contesto di app del servlet.

Inoltre, a seconda delle funzionalità del contesto dell'applicazione Web potrebbe rendere l'applicazione un po 'più difficile da testare e potrebbe essere necessario utilizzare la classe MockServletContext per i test.

Differenza tra servlet e contesto root Spring consente di creare gerarchie di contesto per applicazioni multilivello, quindi il bean richiesto verrà recuperato dal contesto padre se non è presente nel contesto dell'applicazione corrente. In applicazioni web di default ci sono due livelli di gerarchia, radice e servlet contesti: .

Ciò consente di eseguire alcuni servizi come singoli punti per l'intera applicazione (i bean Spring Security e i servizi di accesso al database di base in genere risiedono qui) e un altro come servizi separati nei servlet corrispondenti per evitare conflitti di nomi tra bean. Ad esempio, un contesto servlet servirà le pagine Web e un altro implementerà un servizio Web senza stato.

Questa separazione a due livelli viene fuori dalla scatola quando si usano le classi servlet di primavera: per configurare il contesto dell'applicazione root è necessario usare il tag context-param nel proprio 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>

(il contesto dell'applicazione root è creato da ContextLoaderListener che è dichiarato in web.xml

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

) e tag servlet per i contesti dell'applicazione servlet

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

Si noti che se init-param verrà omesso, in questo esempio spring utilizzerà myservlet-servlet.xml.

Vedi anche: Differenza tra applicationContext.xml e spring-servlet.xml in Spring Framework

Tornando ai giorni di Servlet, web.xml può avere solo uno <context-param>, quindi solo un oggetto di contesto viene creato quando il server carica un'applicazione e i dati in quel contesto vengono condivisi tra tutte le risorse (es: servlet e JSP). È come avere il nome del driver del database nel contesto, che non cambierà. Allo stesso modo, quando dichiariamo il parametro contextConfigLocation in <contex-param>Spring crea un oggetto Contesto applicazione.

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

È possibile avere più servlet in un'applicazione. Ad esempio, potresti voler gestire / proteggere / * richieste in un modo e / non-seucre / * in un altro modo. Per ciascuno di questi servlet è possibile avere un oggetto context, che è 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>

La risposta accettata è terminata, ma su questo c'è una spiegazione ufficiale:

WebApplicationContext è un'estensione del semplice ApplicationContext che presenta alcune funzionalità extra necessarie per le applicazioni Web. Si differenzia da un normale ApplicationContext in quanto è in grado di risolvere temi (consultare Uso dei temi) e di sapere a quale Servlet è associato (avendo un collegamento a ServletContext). WebApplicationContext è associato a ServletContext e utilizzando metodi statici sulla classe RequestContextUtils è sempre possibile cercare WebApplicationContext se è necessario accedervi.

Citato dal riferimento del framework web Spring

A proposito servlet e contesto root sono entrambi webApplicationContext:

ApplicationContext (contesto dell'applicazione radice): ogni applicazione Web Spring MVC ha un file applicationContext.xml che è configurato come radice della configurazione del contesto. Spring carica questo file e crea un applicationContext per l'intera applicazione. Questo file viene caricato da ContextLoaderListener, configurato come parametro di contesto nel file web.xml. E ci sarà solo un applicationContext per applicazione web.

WebApplicationContext: WebApplicationContext è un contesto di applicazione Web compatibile, ovvero contiene informazioni sul contesto servlet. Una singola applicazione Web può avere più WebApplicationContext e ogni servlet Dispatcher (che è il front controller dell'architettura Spring MVC) è associato a WebApplicationContext. Il file di configurazione webApplicationContext * -servlet.xml è specifico di un DispatcherServlet. E poiché un'applicazione Web può avere più di un servlet dispatcher configurato per soddisfare più richieste, può esserci più di un file webApplicationContext per applicazione Web.

Il contesto dell'applicazione Web , specificato WebApplicationContextdall'interfaccia, è un contesto dell'applicazione Spring per un'applicazione Web. Ha tutte le proprietà di un normale contesto dell'applicazione Spring, dato che l' WebApplicationContextinterfaccia estende l' ApplicationContextinterfaccia e aggiunge un metodo per recuperare l'API Servlet standard ServletContextper l'applicazione Web.

Oltre agli ambiti bean Spring standard singletone prototype, sono disponibili tre ambiti aggiuntivi in ​​un contesto di applicazione Web:

• request- applica una definizione di singolo bean al ciclo di vita di una singola richiesta HTTP; vale a dire, ogni richiesta HTTP ha la sua istanza di un bean creata sul retro di una definizione di singolo bean
• session - applica una definizione di singolo bean al ciclo di vita di una sessione HTTP
• application - applica una definizione di singolo bean al ciclo di vita di a ServletContext