ApplicationContext и ServletContext
Я запутался между двумя ApplicationContext и ServletContext, когда дело доходит до Spring MVC Application. Я знаю, что существует только одно приложение ApplicationContext для весеннего веб-приложения, а также только один сервер ServletContext для каждого веб-приложения. Чтобы инициировать значение как для ApplicationContext, так и для ServletContext, в web.xml мы добавим что-то в тег context-param.
Это то, что меня смущает. Каковы различия между этими двумя (я знаю, что ApplicationContext имеет некоторые методы работы с bean-компонентами)? и Когда мы будем использовать ApplicationContext и Когда мы будем использовать ServletContext?
Ответы
Ответ 1
Контекст сервлета:
Он инициализируется при развертывании приложения сервлета. Контекст сервлета содержит все конфигурации (init-param, context-params и т.д.) Всего приложения сервлета.
Контекст приложения:
Это особенность весны. Инициализируется spring. Он содержит все определения bean-компонентов и жизненный цикл bean-компонентов, определенных в файлах конфигурации Spring. Servlet-Context не имеет ни малейшего представления об этом.
Существует два типа контекстов в Spring: родительский и дочерний.
Родительский контекст Spring (контекст приложения/корневой контекст)
<listener>
<listener-lass>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/service-context.xml,
/WEB-INF/dao-context.xml,
/WEB-INF/was-context.xml,
/WEB-INF/jndi-context.xml,
/WEB-INF/json-context.xml
</param-value>
</context-param>
ролевая специально из-ContextLoaderListener в пружине
Spring-ContextLoaderListener-И-DispatcherServlet-Concepts
Когда запускается контейнер Spring, он считывает все определения bean-компонентов из файлов конфигурации и создает объекты bean-объектов и управляет жизненным циклом объектов bean-компонентов. Эта конфигурация совершенно необязательна.
DispatcherServlet vs ContextLoaderListener
fooobar.com/questions/41157/...
Дочерний контекст Spring (WebApplicationContext/Child Context)
<servlet>
<servlet-name>myWebApplication</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>myWebApplication</servlet-name>
<url-pattern>/app/*</url-pattern>
</servlet-mapping>
Когда запускается весеннее веб-приложение, оно ищет файл конфигурации Spring Bean myWebApplication-servlet.xml. Он будет читать все определения компонентов, создавать и управлять жизненным циклом объектов объектов. Если доступен родительский весенний контекст, он объединит дочерний весенний контекст с родительским весенним контекстом. Если родительский контекст Spring недоступен, приложение будет иметь только дочерний контекст Spring.
Ответ 2
Это разные вещи. Все веб-приложения Java, основанные на технологии Servlet, будут иметь контекст сервлета, будь то приложение весны или нет. Напротив, ApplicationContext - вещь Весна; в очень простых терминах, это контейнер для хранения весенних бобов.
Чтобы инициировать значение как для ApplicationContext, так и для ServletContext, в web.xml мы добавим что-то в тег context-param.
Это поможет, если вы приведете пример для этого, потому что, насколько мне известно, context-param используется для ServletContext, а не ApplicationContext.
Обновление:
Вы можете использовать context-param
чтобы обеспечить расположение файлов конфигурации контекста корневого приложения, как показано ниже.
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/root-context.xml
/WEB-INF/applicationContext-security.xml
</param-value>
</context-param>
Ответ 3
В Spring, чтобы прочитать определенный файл конфигурации инициализации, мы используем context-param с предопределенным именем, называемым contextConfigLocation.
<context-param>
<description>WebFlow context configuration</description>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/test-context.xml</param-value>
</context-param>
Но в случае веб-приложения Plain J2EE без включения каких-либо фреймворков контекстный параметр может считываться из любого места в приложении, то есть любого сервлета, фильтра.
Разница между ApplicationContext и ServletContext объясняется санджаем
Ответ 4
ApplicationContext - контейнер Spring.
Он использовал для объединения конфигураций из весенних бобах вместе и использовал их для приложения.
Используйте ApplicationContext, если вы хотите получить информацию о Spring beans.
Используйте ServletContext, если вы хотите получить/установить атрибут, общий для всех Servlet.
Ответ 5
ServletContext
отличается от "включающего" ApplicationContext
. Документ Java говорит ниже для ServletContext
Существует один контекст [сервлет] для каждого "веб-приложения" на виртуальную машину Java. ("Веб-приложение" - это набор сервлетов и контента, установленных в определенном подмножестве пространства имен URL-адреса сервера, например /catalog, и, возможно, установленных через файл .war.)
Поскольку в одной и той же AppBase
может быть несколько "веб-приложений", каждое из которых имеет собственный DocBase
, WEB-INF/web.xml
и т.д., Определенно существует общая среда/контекст, общий для всех "веб-приложений", который упоминается как ApplicationContext
. В случае JSF PortletContext
является противоположной частью ServletContext
а ApplicationContext
называется ExternalContext
.