Несколько контекстов приложения, несколько сервлетов диспетчера?

До сих пор я думал, что веб-приложение может иметь только один dispatcher-servlet, который мы определили в web.xml

  • Правильно ли я так думаю?
  • Могу ли я иметь несколько сервлетов-диспетчеров в одном веб-приложении? Если да, то как?
  • В какой ситуации нам это может понадобиться?
  • Может ли быть только один контекст приложения во всем веб-приложении?
  • Как мы можем определить несколько контекстов приложения?
  • Может ли dispatcher-servlet существовать в непружинном приложении?

Ответы

Ответ 1

У вас есть несколько сервлетов диспетчера в одном веб-приложении?

Конечно, цитирование официальной документации ( жирный на самом деле там!)

Веб-приложение может определять любое количество DispatcherServlets. Каждый сервлет будет работать в своем собственном пространстве имен, загружая свой собственный контекст приложения с помощью сопоставлений, обработчиков и т.д. Только общий контекст корневого приложения, загружаемый ContextLoaderListener, если таковой имеется, будет разделяться.

Как?

Просто объявите несколько сервлетов с разными именами, но используя класс org.springframework.web.servlet.DispatcherServlet. Также убедитесь, что файл yourServletName-servlet.xml доступен.

Какая ситуация может нам понадобиться?

DispatcherServlet очень гибкий. Не только Spring использует MVC, но также поддерживает Spring WS, Spring для hessian и т.д.

Кроме того, может ли быть только один контекст приложения во всем веб-приложении?

Отвечено уже в цитированной документации: один контекст приложения на DispatcherServlet + один основной контекст веб-приложения.

Как определить несколько контекстов приложения?

См. выше, просто создайте несколько DispatcherServlet s.

Может ли сервлет диспетчера существовать в приложении spring?

DispatcherServlet является контекстом Spring (приложение Spring), таким образом: no. На руке DispatcherServlet можно объявить в приложении, не имеющем родительского (основного) контекста приложения, таким образом: да.

Ответ 2

  В какой ситуации нам это может понадобиться?

OR
 Преимущества нескольких диспетчерских сервлетов OR
 Зачем нам нужно несколько диспетчерских сервлетов?

Простой ответ - иметь функциональность DispatcherServlet в нескольких формах

Функциональные возможности сервлет-диспетчера

  • Сервлет-диспетчер использует реализацию HandlerMapping для управления маршрутизацией запросов к объектам-обработчикам. По умолчанию используется BeanNameUrlHandlerMapping и RequestMappingHandlerMapping.
  • Стратегия разрешения его представления может быть задана с помощью реализации ViewResolver, разрешающей символические имена представлений в объекты View. По умолчанию используется InternalResourceViewResolver.
  • Стратегия разрешения исключений может быть указана с помощью HandlerExceptionResolver, например, для сопоставления определенных исключений со страницами ошибок.
  • Стратегия разрешения многочастных запросов определяется реализацией MultipartResolver.
  • Стратегия разрешения локали определяется LocaleResolver.
  • Стратегия разрешения темы определяется ThemeResolver.

Я попытаюсь объяснить некоторые из функций, предоставляемых DispatcherServlet

Объявление нескольких сервлетов-диспетчеров
Предположим, у нас есть два сервлета диспетчера (DS), где DS1, DS2 настроены с разными шаблонами URL (**.simple, **.beanName), и они используют разные конфигурации сервлета диспетчера, представленные ниже.

DispatcherServlet     - simpleUrlHandlerDispatcherServlet
contextConfigLocation - /WEB-INF/simpleUrlHandlerMapping.xml
<url-pattern>*.simple</url-pattern>

DispatcherServlet     - beanNameUrlHandlerDispatcherServlet
contextConfigLocation - /WEB-INF/beanNameUrlHandlerMapping.xml
<url-pattern>*.beanName</url-pattern>

Advantage 1: У нас может быть разное HandlerMapping для разных наборов URL

Конфигурация отображения обработчика URL-адреса имени bean-компонента DS1

<bean name="/hello.beanName" class="com.pvn.mvc.HelloController" />
<bean name="/hi.beanName" class="com.pvn.mvc.HiController" />

DS2 конфигурация отображения простого URL-адреса

<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="mappings">
        <props>
            <prop key="/hello.simple">simpleHello</prop>
            <prop key="/hi.simple">simpleHi</prop>
        </props>
    </property>
</bean>

Advantage 2: У нас может быть другой распознаватель для разных наборов URL.

InternalResourceViewResolver для DS1
где он имеет дело только с prefix + returned String + suffix.
TilesViewResolver для DS2
его реализация обеспечивается Apache тайлами, которые представляют собой высокоуровневую функциональность плагина на основе макета/скелета, как указано ниже.
enter image description here Или если мы используем TilesViewResolver с другим макетом для другого набора URL-адресов
анонимный пользователь - другой макет
авторизовался пользователь - другой макет

Advantage 3: У нас может быть другой распознаватель тем для разных наборов URL.
Эти средства распознавания постоянно следят за cookie/сессией для разрешения темы и подают квалифицированную таблицу стилей/тему (как показано на рисунке ниже). Ниже приведен только пример для результата CookieThemeResolver.
Примечание. Речь идет не о настройке темы, а о настройке распознавателя темы.

enter image description here

Advantage 4: У нас может быть другой преобразователь локали для другого набора URL.
Эти средства распознавания постоянно отслеживают cookie/session/accept-header для разрешения локали и загружают квалифицированное сообщение приложения (как показано на рисунке ниже). Ниже приведен только пример для результата CookieLocaleResolver.
Примечание. Речь идет не о настройке локали, а о настройке преобразователя локали.
enter image description here