В чем разница между ApplicationContext и WebApplicationContext в Spring MVC?

В чем разница между контекстом приложения и контекстом веб-приложения?

Я знаю, что WebApplicationContext используется для ориентированных на Spring MVC приложений?

Я хочу знать, что такое использование ApplicationContext в приложениях MVC? И какие бобы определены в ApplicationContext?

Ответ 1

Контекст веб-приложения расширенный контекст приложения, который предназначен для работы со стандартным javax.servlet.ServletContext, чтобы он мог общаться с контейнером.

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

Beans, созданный в WebApplicationContext, также сможет использовать ServletContext, если они реализуют интерфейс ServletContextAware

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

Существует много возможностей с экземпляром ServletContext, например, для доступа к ресурсам WEB-INF (конфигурации xml и т.д.), вызывая метод getResourceAsStream(). Как правило, все контексты приложения, определенные в web.xml в приложении сервлета Spring, являются контекстами веб-приложений, это касается как корневого контекста webapp, так и контекста приложения сервлета.

Кроме того, в зависимости от возможностей контекста веб-приложения ваше приложение может быть сложнее протестировать, и вам может потребоваться использовать MockServletContext class для тестирования.

Разница между сервлет и корневым контекстом Spring позволяет создавать многоуровневые иерархии контекста приложений, поэтому требуемый bean будет извлекаться из родительского контекста, если он не присутствует в текущем контексте приложения. В веб-приложениях по умолчанию установлены два уровня иерархии, контекст корня и сервлета: Servlet and root context.

Это позволяет вам запускать некоторые сервисы в качестве синглтонов для всего приложения (Spring Безопасность beans и обычно здесь находятся базовые службы доступа к базам данных), а другой - как разделенные службы в соответствующих сервлетах, чтобы избежать конфликтов имен между beans. Например, один контекст сервлета будет обслуживать веб-страницы, а другой будет реализовывать веб-службу без состояния.

Это разделение на два уровня выходит из строя, когда вы используете классы сервлетов Spring: для настройки корневого контекста приложения вы должны использовать тег context-param в своем 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>

(контекст корневого приложения создается ContextLoaderListener, который объявлен в web.xml

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

) и тег сервлета для контекстов приложения сервлета

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

Обратите внимание, что если init-param будет опущен, то Spring будет использовать myservlet-servlet.xml в этом примере.

См. также: Разница между applicationContext.xml и spring -servlet.xml в Spring Framework

Ответ 2

ApplicationContext applicationContext.xml - это настройка корневого контекста для каждого веб-приложения. Spring загружает файл applicationContext.xml и создает ApplicationContext для всего приложения. В каждом веб-приложении будет только один контекст приложения. Если вы явно не объявляете имя файла конфигурации контекста в web.xml с помощью параметра contextConfigLocation, Spring будет искать applicationContext.xml в папке WEB-INF и бросать FileNotFoundException, если он не может найти этот файл.

WebApplicationContext Помимо ApplicationContext, в одном веб-приложении может быть несколько WebApplicationContext. Говоря простыми словами, каждый DispatcherServlet связан с одним WebApplicationContext. Файл xxx-servlet.xml специфичен для DispatcherServlet, и веб-приложение может иметь более одного DispatcherServlet, настроенных для обработки запросов. В таких сценариях каждый DispatcherServlet должен иметь отдельный xxx-servlet.xml. Но applicationContext.xml будет распространен для всех файлов конфигурации сервлета. Spring будет по умолчанию загружать файл с именем "xxx-servlet.xml" из папки webapps WEB-INF, где xxx - это имя сервлета в web.xml. Если вы хотите изменить имя этого имени или изменить местоположение, добавьте параметр init-param с contextConfigLocation как имя параметра.

Ответ 3

Возвращаясь к дням сервлета, web.xml может иметь только один <context-param>, поэтому создается только один объект контекста, когда сервер загружает приложение, а данные в этом контексте распределяются между всеми ресурсами (например: сервлеты и JSP), Это то же самое, что и имя драйвера базы данных в контексте, которое не изменится. Аналогичным образом, когда мы объявляем параметр contextConfigLocation в <contex-param> Spring, создается один объект контекста приложения.

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

В приложении может быть несколько сервлета. Например, вы можете обрабатывать/защищать/* запросы одним способом и/не-seucre/* другим способом. Для каждого из этих сервлетов вы можете иметь объект контекста, который является 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>

Ответ 4

Принятый ответ исчерпан, но на это есть официальное объяснение:

WebApplicationContext является расширением простого ApplicationContext, который имеет некоторые дополнительные функции, необходимые для веб-приложений. Он отличается от обычного ApplicationContext тем, что способен разрешать темы (см. "Использование тем") и знает, с каким сервлетом он связан (имея ссылку на ServletContext). WebApplicationContext связан с ServletContext, и с помощью статических методов в классе RequestContextUtils вы всегда можете найти WebApplicationContext, если вам нужен доступ к нему.

Цитируется из ссылки на веб-фреймворк Spring

Кстати, сервлет и корневой контекст оба являются webApplicationContext:

Typical context hierarchy in Spring Web MVC

Ответ 5

ApplicationContext (корневой контекст приложения). Каждое веб-приложение Spring MVC имеет файл applicationContext.xml, который настроен как корневой каталог конфигурации контекста. Spring загружает этот файл и создает applicationContext для всего приложения. Этот файл загружается ContextLoaderListener, который настроен как параметр контекста в файле web.xml. И будет только один applicationContext для каждого веб-приложения.

WebApplicationContext: WebApplicationContext - это контекст приложения с веб-интерфейсом, т.е. Он содержит информацию о контексте сервлета. Одно веб-приложение может иметь несколько WebApplicationContext, и каждый сервлет Dispatcher (являющийся фронт-контроллером архитектуры Spring MVC) связан с WebApplicationContext. Файл конфигурации webApplicationContext * -servlet.xml относится только к DispatcherServlet. А поскольку в веб-приложении может быть настроено несколько сервлетов-диспетчеров для обслуживания нескольких запросов, в веб-приложении может быть несколько файлов webApplicationContext.