Spring-MVC: что такое «контекст» и «пространство имен»?

Question

Из XmlWebApplicationContext javadoc:

По умолчанию конфигурация будет взята из "/WEB-INF/applicationContext.xml" для корневого контекста и "/ WEB-INF / test-servlet.xml "для контекста с пространством имен" test-servlet "(как для экземпляра DispatcherServlet с именем сервлета" test ").

Что это означаетВесенний контекст?

Что такое корневой контекст?Какие другие виды контекста Spring существуют?

Что такое пространство имен?

ОБНОВЛЕНИЕ:

Некоторые дополнительные вопросы:

1. Что такое Spring ApplicationContext - это какая-то «вещь», которая содержит компоненты, определенные в файле конфигурации XML?

2. Просмотр кодаContextLoaderListener, похоже, он загружает данные, определенные в XML-файле (ах) config.Но мое веб-приложение Spring работает без определения этого слушателя или любого другого слушателя.Как это может быть?

3. В каких случаях имеет смысл иметь более одного экземпляра Spring DispatcherServlet?

4. Является ли корневой контекст(данные из applicationContext.xml) применимы к каждому экземпляру DispatcherServlet, а другие контексты (например, данные из test-servlet.xml) применимы только к соответствующему DispatcherServlet (т. е. test)?

Answer 1

«Spring context» = a Spring ApplicationContext .

«корневой контекст» в терминах веб-приложения означает основной контекст, который загружается и используется веб-приложением.Как правило, корневой контекст запускается с ContextLoaderListener .

Корневой контекст на самом деле не является «своего рода» контекстом.Это просто роль, которую играет контекст.У вас есть один корневой контекст в веб-приложении.Другие контексты не являются корневым контекстом.Обычно они являются потомками корневого контекста.

Пространство имен здесь относится к области действия экземпляра Spring DispatcherServlet.Все, что здесь говорится, это то, что если вы назовете свой сервлет «test» в своем файле web.xml, то, по соглашению, Spring будет искать файл с именем «test-servlet.xml» для использования в качестве контекста этого диспетчера.Между прочим, каждый подобный контекст, который создается для диспетчера, становится потомком корневого контекста.

Редактировать: Чтобы ответить на ваши новые вопросы:

1. Следуйтессылка в первой строке моего ответа, чтобы узнать о ApplicationContext.Если у вас есть вопросы, на которые нет ответов, я бы предложил опубликовать новый вопрос SO.
2. Корневой контекст не является обязательным.Если вы не определили ContextLoaderListener, то у вас просто нет корневого контекста.Когда вы используете DispatcherServlet, он запускает свой собственный ApplicationContext и получает оттуда нужные ему бины.
3. Я не знаю ни одного из них на моей голове.Я полагаю, что если бы некоторые ресурсы URL в вашем приложении требовали кардинально разных конфигураций, это могло бы побудить вас сделать это.
4. Да.Чтобы сформулировать это в правильных терминах, корневой контекст является родительским контекстом любого контекста, запущенного для DispatcherServlet.Бины в родительском контексте доступны через дочерний контекст, но обратное неверно.

Answer 2

В веб-приложении архитектура обычно делится на слои, подобные популярной структуре MVC.Таким образом, веб-приложение состоит в основном из уровня, который обрабатывает клиентские запросы, то есть HTTPRequests, и уровня, который обслуживает эти запросы.

Подводя итог: классы, предназначенные для обработки запросов Http, т.е. контроллеры, которые отображаются на URL-адреса, входят в test-servlet.xml.Это называется WebapplicationContext, содержащим только компоненты, которые требуются в основном для обработки клиентских запросов.

Теперь следующая часть - это уровень Service / Dao, который включает вашу бизнес-логику.Бины, выполняющие такую ​​логику, загружаются в объекте ApplicationContext.

Теперь вы можете спросить, почему они разделили эти вещи на файлы или два разных объекта.

Это потому, что приложение имеет одинаковый бизнеслогика, которая может использоваться несколькими клиентами, работающими по разным протоколам.Вы можете использовать те же уровни обслуживания для обработки RMI, а также HTTP-вызовов.Поэтому Spring создал родительский контекст, который запускается нами как ApplicationContext.И затем, если ваше приложение обрабатывает веб-запросы, вы можете создать сервлет диспетчера, который имеет собственный контекст Webapplication и инициализируется как дочерний элемент родительского контекста.Таким образом, на все родительские бины можно ссылаться в потомке, и они могут быть переопределены, но не наоборот